[m-rev.] for review: unboxed floats in high-level C grades

[Julien Fischer]

Hi Peter,

On Thu, 18 Aug 2011, Peter Wang wrote:

> Branches: main
>
> Support unboxed float fields in high-level C grades.
>
> When the representation of `float' is no wider than a machine word, d.u.
> functor arguments of type `float' (or equivalent) will be stored directly
> within cells constructed for that functor, instead of a pointer to the box
> containing the value.  This was already so for low-level C grades.
>
> compiler/mlds.m:
> 	Add an option to mlds_type, equivalent to
> 	`mlds_array_type(mlds_generic_type)' except that some elements are
> 	known to be floats.
>
> 	Update some comments.
>
> compiler/ml_global_data.m:
> 	Remember the `--unboxed-float' option in `ml_global_data'.
>
> 	Special case generic arrays in `ml_gen_static_scalar_const_addr' and
> 	`ml_gen_static_scalar_const_value'.  Float literals cannot be used to
> 	initialize an element of a generic array in C.  If any appear, replace
> 	the generic array type by an instance of
> 	`mlds_mostly_generic_array_type' with float fields in the positions
> 	which have float initializers.
>
> compiler/ml_code_util.m:
> 	Make `ml_must_box_field_type' and `ml_gen_box_const_rval' depend on the
> 	`--unboxed-float' option.
>
> 	Delete some now-misleading comments.
>
> 	Delete an unused predicate.
>
> compiler/mlds_to_c.m:
> 	Update code that writes out scalar static data to handle
> 	`mlds_mostly_generic_array_type'.
>
> 	In one case, for `--high-level-data' only, output float constants by
> 	their integer representation, so that they may be cast to pointer
> 	types.

Technically you should avoid doing that when --cross-compiling is
enabled, but it probably isn't too important as the main use of that
option is for building the source distribution and we don't support that
in grades that use --high-level-data anyway.

> compiler/ml_unify_gen.m:
> 	Rename some predicates for clarity.
>
> compiler/ml_accurate_gc.m:
> compiler/ml_lookup_switch.m:
> compiler/ml_proc_gen.m:
> compiler/ml_simplify_switch.m:
> compiler/mlds_to_cs.m:
> compiler/mlds_to_gcc.m:
> compiler/mlds_to_il.m:
> compiler/mlds_to_java.m:
> 	Conform to changes.
>
> library/float.m:
> 	Add hidden functions to return the integer representation of the bit
> 	layout of floating point values.
>
> library/exception.m:
> 	Delete mention of MR_AVOID_MACROS.
>
> runtime/mercury.c:
> runtime/mercury.h:
> 	Make MR_box_float/MR_unbox_float act like "casts" when MR_BOXED_FLOAT
> 	is undefined, and only define them in high-level grades.  I think they
> 	should be replaced by MR_float_to_word/MR_word_to_float (which have
> 	less confusing names when there is no boxing) but that would require
> 	some header file reshuffling which I don't want to undertake yet.
>
> 	Delete references to MR_AVOID_MACROS.  Apparently it existed to support
> 	the defunct gcc back-end but I cannot see it ever being defined.
>
> runtime/mercury_conf_param.h:
> 	MR_HIGHLEVEL_CODE no longer implies MR_BOXED_FLOAT.
>
> 	Delete mention of MR_AVOID_MACROS.
>
> runtime/mercury_float.h:
> 	Fix a comment.
>
> tests/hard_coded/Mmakefile:
> tests/hard_coded/float_ground_term.exp:
> tests/hard_coded/float_ground_term.m:
> 	Add a test case.

...


> diff --git a/compiler/mlds.m b/compiler/mlds.m
> index 5cea540..d66279f 100644
> --- a/compiler/mlds.m
> +++ b/compiler/mlds.m
> @@ -815,6 +815,15 @@
>             %     MLDS code generator, e.g. the arrays used for
>             %     string switches.
>
> +    ;       mlds_mostly_generic_array_type(list(mlds_type))
> +            % A generic array with some float elements.

What do you mean by "some"?  Are other elements not going to be
floats?

> +            %
> +            % This is the same as mlds_array_type(mlds_generic_type) except
> +            % that some element types are mlds_native_float_type instead of
> +            % mlds_generic_type.

That begs the question, why is it not called something like
mlds_float_array_type?  (Do you envisage it being used for element types
other than floats in the future?)

> In C, it is not possible to initialize an
> +            % element of a generic array with a float literal, so we replace
> +            % them with a structure type with some float fields.

That looks good otherwise.

(Incidentally, I've added a version of the n-body benchmark from the
programming language shootout or whatever it calls itself these days
to the benchmarks; you may want to try this change out on it -- it should
make a substantial difference**.)

Cheers,
Julien.

** on eris the hlc.gc grade is currently a *lot* slower than the java
grade with this benchmark and a large part of is due to the boxing issue
you've fixed here.




--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------