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

[Zoltan Somogyi]

> > runtime/mercury_conf.h.in:
> > 	Mention the macros used by the configure script, INT32_TYPE
> > 	and INT16_TYPE.
> > 
> > runtime/mercury_conf_param.h:
> > 	Document the macros used by the configure script, INT32_TYPE
> > 	and INT16_TYPE.
> 
> Those macros should have an `MR_' prefix.

OK; I added one to WORD_TYPE as well.

> > compiler/llds.m:
> > 	Modify the create rval in two ways. First, add an extra argument to
> > 	represent the types of the arguments, which used to always be implicit
> > 	always a word in size, but may now be explicit and possibly smaller
> > 	(e.g. uint8). Second, since the code generator would do the wrong
> > 	thing with creates with smaller than wordsize arguments, replace
> > 	the old must-be-unique vs may-be-nonunique bool with a three-valued
> > 	marker, must_be_dynamic vs must_be_static vs can_be_either.
> 
> 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, for no real gain, since most types manipulated
by Mercury programs are word sized for a reason.

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

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

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

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

I will reword the message to say >= 32-bits instead of just 32 bits.

> 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, including
the test for WORD_TYPE, which I think *you* wrote.

The relative diff will follow in a while.

Zoltan.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------