[m-dev.] arg packing of structured values

[Julien Fischer]

Hi Zoltan

On Thu, 26 Jul 2018, Zoltan Somogyi wrote:

> Given the types
>
> :- type t1
>    --->    t1f1(bool, bool).
>
> :- type t2
>    --->    t2f1(bool, bool, bool).
>
> that the compiler will soon be able to represent in less than
> one word each (I am working on that now), consider this type:
>
> :- type t
>    --->    tf(t1, int8, t2).
>
> With our current type representation, this will occupy three words
> on the heap even if argument packing is turned on, because we can
> now pack two or more arguments into a word only if the arguments
> are either enums or sub-word-sized integers. While types t1 and t2
> fall into neither category, their representations *do* occupy a known,
> small number of bits. It should therefore be possible to represent
> values of type t in less than one word, *without* any heap allocation,
> by giving them the same representation as we would give to
>
> :- type t'
>    --->    tf'(bool, bool, int8, bool, bool, bool).
>
> Something similar should also be possible if t1 and t2 have
> more than one function symbol, as long as *all* of them
> are representable in less than a word.
>
> My question for you guys is: would this be a useful thing to implement?

Another question: as a programmer how much, if any, control would I (or
indeed the compiler) have over it occurring?  If my program spends a lot
of its time manipulating t1 and t2 values as independent entities then
it may be better for t values to just contain pointers to those
arguments.  (I'm thinkg of the case where the first and third arguments
of the t value above are extracted many times.)  On the other hand, if
the program really uses t as a record then the flattening proposed here
would be worthwhile.

> Do you know of any set of types in programs you know of to which
> this optimization is applicable?

I suspect not, firstly because sub-word sized integers at not yet very
common in most of the code I work with and secondly, where such nesting
has occurred in the past (older versions of the Zinc compiler spring to
mind), it has already long since been flattened by hand.

> Or should I try to find such type sets by implementing the
> applicability test for this optimization, and getting the compiler to
> spit out informational messages about any types for which the test
> succeeds?

I think that's worth trying.

Unrelated question: does argument packing also apply to the character
type (on 64-bit systems)?

Julien.