[m-dev.] for review: compressing RTTI using non-word creates (part 1)

[Fergus Henderson]

On 27-Apr-1999, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> > Hmm, wouldn't it be better to modify the code generator so that it can
> > cope with creates that have non-word-sized arguments?
> 
> Are you volunteering?
> 
> That would require changing the Mercury abstract machine, which requires
> rewriting much of the code generator, and significant modifications
> to the LLDS optimizations,

Ok, you convinced me on this one.

> > It looks to me like this change will break the `--no-static-ground-terms'
> > option.
> 
> As submitted, yes. However, I changed llds_out so that when creating
> a structure whose arg types are specified, it does not put casts on
> the field initializers. This preserves the only real current use of
> --no-static-ground-terms, which is ANSI C compatibility.
> Ever since we started generating layout structures, they were always
> created static regardless of the value of the option. I have now documented
> this.

Fine.  Please post a relative diff of your new changes.

> > > compiler/llds_common.m:
> > > 	Don't conflate creates with identical argument values but different
> > > 	argument types.
> > 
> > Why not?  If the argument types have the same size, then this optimization
> > should still be applicable.
> 
> In theory, you are right. In practice, there is no point, because cells
> creates with different type arguments are very unlikely to have the same
> contents.

OK.  Having looked at the code in more detail, I realize that the types
involved are the C types (e.g. `Word', `int_least32_t', etc.), rather
than the Mercury types, and seeing from the source code that it would
be a fair amount of work to change this, I agree that it is not worth
the effort.

> > > compiler/code_exprn.m:
> > > 	If a create is marked must_be_static, don't inspect the arguments
> > > 	to decide whether it can be static or not.
> > 
> > Would it be better to inspect the arguments
> > and call error/1 in case of a conflict?
> 
> At the moment, the only cells we create as must_be_static are guaranteed
> to really be static, so there is no point.

Well, the point would be to verify that this assumption remains true
in the future.  If you mean to say that you don't think this is worth
the effort or worth the efficiency cost, then that's OK with me.

> > It would be better to test SHRT_MAX, INT_MAX, and LONG_MAX,
> > defined in <limits.h>, rather than testing the results of sizeof,
> > since sizeof measures the size in chars, not in bits, and ANSI C
> > only guarantees that CHAR_BIT >= 8 not that CHAR_BIT == 8.
> 
> But CHAR_BIT >= 8 is sufficient for this test.

No, it's not.  If CHAR_BIT is say 16, and you have short=int=long=32 bits,
then sizeof() will return 2 for those types, and so the test for
`INT32_TYPE' will fail, returning `unknown'; this will lead to a syntax
error in the header file.

> > Also testing preprocessor constants is better because it can
> > be done using AC_TRY_COMPILE rather than AC_TRY_RUN, which is
> > better because AC_TRY_RUN doesn't work if you're cross-compiling.
> 
> There is no point, since other tests also use AC_TRY_RUN,

Well, we shouldn't make it any worse.

Another alternative would be to use #if in the header file directly,
that way you don't need to use AC_TRY_COMPILE.

> including the test for WORD_TYPE, which I think *you* wrote.

Nope, you wrote that one. 
Check `cvs annotate configure.in | grep WORD_TYPE' ;-)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------