[m-rev.] for review: representations of complex types in .int files

[Julien Fischer]

Hi Zoltan,

On Wed, 27 May 2020, Zoltan Somogyi wrote:

> On Sat, 23 May 2020 10:11:31 +1000 (AEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>> For review by anyone.
>
> Is anyone intending to look at this?

There are a few spots in this diff where you should be able to use
the support for uints with io.format in order to avoid casts.

I assume that at the moment packing does not consider single-precision
floats on 64-bit platforms?

> Put type_repn items for complex types into .int files.
> 
> compiler/decide_type_repn.m:
>     Previouly, this module computed type_repn items to put into .int3 files

s/Previouly/Previously/

>     for a subset of the type constructors defined in the current module:
>     the direct_dummy, enum and notag types (the *simple* types),
>     and the du types whose representation is guaranteed to be
>     a word-aligned pointer when targeting C. (We care about pointers
>     being word-aligned only when applying the direct arg optimization.
>     This optimization is applicable only with the low level data
>     representation, which we use only when targeting C.)

...

>     Second, since we compute a representation for each type six times,
>     I tried to avoid obvious inefficiencies, but only if the code
>     remained simple. In the future, we may want to use an approach
>     based on the idea that in the process of computing the first
>     representation, we look out for any indication that the representation
>     may be different on any of the other five platforms, and if not,
>     we just reuse the first representation on the other five platforms as well.
>     However, that would be appropriate only *after* we have a simpler
>     system that has proven to work in practice.
>
>     There is a third, smaller change: when deciding whether an argument
>     is packable, we take into account not just equivelence type

s/equivelence/equivalence/

>     definitions, but the definitions of notag types as well.
>     This takes advantage of the fact that if a notag type is abstract
>     exported, its representation is put into the relevant .int3 file
>     even though its definition isn't. (This is why du_type_layout.m
>     couldn't "see through" notag types: it couldn't depend on knowing
>     which types were notags.)
> 
> compiler/prog_item.m:
>     Change the types we use for type representation information.
>     Their previous definitions baked in the assumption that the only
>     distinction between platforms that mattered was the 64 vs 32 bit
>     distinction, which is not the case. 
>
>     Use a more consistent naming scheme for the types we use
>     to represent type representation information.
>
>     Include the "dereferenced" types of the argiments in functors'

s/argiments/arguments/


>     representations. (I use "dereferencing"here to mean expanding

Add a space before "here".

>     equivalence types and throwing away any notag wrappers.).
>     We don't need it when generating C code using the low level
>     data representation, but we do need it to create constructors
>     when generating e.g. Java code that uses the high level data
>     representation.


> compiler/hlds_data.m:
> compiler/prog_data.m:
>     Move the ptag type from hlds_data.m to prog_data.m, to make it
>     accessible in prog_item.m.
>
>     Add some documentation in prog_data.m.

...

> diff --git a/compiler/prog_item.m b/compiler/prog_item.m
> index 285600ace..fb28b70bc 100644
> --- a/compiler/prog_item.m
> +++ b/compiler/prog_item.m
> @@ -1947,8 +1958,56 @@
>      --->    dur_direct_dummy(direct_dummy_repn)
>      ;       dur_enum(enum_repn)
>      ;       dur_notag(notag_repn)
> -    ;       dur_gen_only_functor(gen_du_repn_only_functor)
> -    ;       dur_gen_more_functors(gen_du_repn_more_functors).
> +    ;       dur_gen_only_functor(gen_du_only_functor_repn)
> +    ;       dur_gen_more_functors(gen_du_more_functors_repn).
> +
> +    % When targeting C, many argument packing decisions depend on
> +    % three properties of the target platform, i.e. on the combination
> +    % of tha target hardware and the target grade:

s/tha/the

> +    %
> +    % - whether the target is 64 or 32 bit;
> +    % - whether the grade is an spf (single-precision float) grade; and
> +    % - whether the grade allows the direct arg optimization.
> +    %
> +    % These have eight combinations, but the spf grade component has
> +    % no effect on argument packing on 64 bit targets (a float is one word
> +    % either way), so only six are meaningful.

The rest looks fine; you can go ahead and commit.

Julien.