[m-dev.] argument packing

[Zoltan Somogyi]

On Wed, 16 May 2018 10:36:47 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> The first of those tougher tests would be compiling the standard
> library in the csharp grade with the new optimizations turned on:

The new optimizations are not applicable to the C# and Java grades.
This is because they require working with a single addressable word
containing two or more arguments, but the C# and Java grades,
along with hl.gc, use the high level data representation, which
requires the fields of memory cells to be identified by argument names,
not by offset. A word containing two or more arguments has no name.

>      Making Mercury/css/thread.mvar.cs
>      Making Mercury/css/thread.semaphore.cs
>      Making mer_std.dll
>      ** Error making `mer_std.dll'.
>      Mercury/css/erlang_rtti_implementation.cs(740,113): error CS0029: Cannot
>      implicitly convert type `int' to `mercury.runtime.DuArgLocn'
>      Mercury/css/erlang_rtti_implementation.cs(741,3): error CS0029: Cannot
>      implicitly convert type `int' to `mercury.runtime.DuArgLocn'
>     ... <more snipped>
>      Mercury/css/erlang_rtti_implementation.cs(1445,30): error CS1729: The type
>     `mercury.erlang_rtti_implementation.Maybe_pseudo_type_info_0.Pseudo_1'
>      does not contain a constructor that takes `0' arguments
>      ... error log truncated, see `mer_std.err' for the complete log.
>      gmake[1]: *** [libmer_std.install] Error 1
> 

That, and its Java equivalent in your following email, was almost certainly
caused by the optimization accidentally being left *on*. Please try the
attached diff, which turns them off in high-level-data grades. For me,
it generates the same code for tools/make_java_csharp_diff
as a compiler I installed on 2018 may 2, but that is not as though
a test as a bootcheck. I intend to commit it sometime tomorrow
(minus the change to options.m) if it passes further bootchecks.

 > So if you have compiled the Mercury programs you are working on
> > with an installed compiler which has had its default values of
> > allow_packing_ints and allow_packing_dummies set to `yes',
> > and had those programs pass all their tests, please tell me.
> > If you haven't, then please do so and tell me.
> > And if you had any failures, please tell me as well.
> 
> I'll try a bunch of Opturion's stuff with the new optimizations enabled.
> What's the best way to determine if the new optimizations have been
> applied?

There is no really simple way. You have to look at some code that
constructs or deconstructs a term that contains two or more adjacent
arguments whose type is either dummy, or a sub-word-sized integer,
and then check whether it packs or unpacks those arguments. Finding
the right code to check is much easier if you compare the generated code
to the code generated without --allow-packing-ints and --allow-packing-dummies.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.hld
Type: application/octet-stream
Size: 249 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/developers/attachments/20180517/45a55532/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.hld
Type: application/octet-stream
Size: 4359 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/developers/attachments/20180517/45a55532/attachment-0001.obj>