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

[Zoltan Somogyi]

On Wed, 27 May 2020 21:17:40 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> 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.

Ok, but that will require updating configure.ac to require a very recent
compiler. I think I will leave that for a followup change, after I install
a compiler that has your recent changes :-)
 
> I assume that at the moment packing does not consider single-precision
> floats on 64-bit platforms?

While spf works differently than non-spf grades on 64 bit platforms,
the current implementation reserves full word for a float on 64 bit
machines with or without spf. This diff preserves that behavior.
So this diff "considers" spf on 64 bit platforms by ignoring it :-)

We could try treating floats in spf grades the same way we treat
int32s, allowing them to be packed together with other sub-word-sized
values, but that would be a separate change. I for one don't think
that change is at all urgent.

> > compiler/decide_type_repn.m:
> >     Previouly, this module computed type_repn items to put into .int3 files
> 
> s/Previouly/Previously/

Fixed.

> >     There is a third, smaller change: when deciding whether an argument
> >     is packable, we take into account not just equivelence type
> 
> s/equivelence/equivalence/

Fixed.

> >     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/

Fixed, and a spellcheck run.

> 
> >     representations. (I use "dereferencing"here to mean expanding
> 
> Add a space before "here".

Done.

> > +    % 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

Done.

> > +    %
> > +    % - 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.

Thanks for the review.

Zoltan.