[m-dev.] for review: --no-special-preds

[Zoltan Somogyi]

On 01-Apr-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > 	and a proper __Compare__ predicate, since this is the only convenient
> > 	way to generate the full type name for the error message at runtime
> > 	(due to polymorphism, the full type may not be known at compile time).
> 
> How about using the ML_type_name function that is exported from std_util.m?
> 
> (That is a minor efficiency issue and can be addressed as a separate change.
> For this change, just adding a comment about it would be fine.)

Actually, such exceptions will almost always indicate a program bug, and should
thus not be caught. Efficiency is therefore not important.

The real reason why that approach may be preferable is that it saves a small
amount of code space per type with user-defined equality. Since such types are
few, this is not a compelling reason either.

> > 	enumerations, we were only specializing compare in mode 0, when modes
> > 	0 through 3 have identical code (they differ only in uniqueness
> > 	requirements on the arguments).
> 
> I'm not sure that this specialization is safe, because the resulting code is
> not be well-moded.

The transformation I made should only ever be casting away the uniqueness
information from (a) builtins and (b) enum types without user-defined equality.
I don't believe that any part of the compiler after unique mode checking
is as yet interested in the uniqueness of values of such types.

However, the problem can in any case be avoided reasonably simply, by adding
three new modes (out,ui,in), (out,in,ui) and (out,ui,ui) for the comparison
preds of the builtin types, and making sure that the transformation preserves
the mode. OTOH, this may slow down ordinary mode checking for all other calls
to these preds. Since there are probably not too many such calls, I will make
the change, but this will require everybody to recompile everything yet again
:-(

BTW, using a compiler compiled --no-special-preds produces a slow-down, not a
speedup, from 56s to 62s, when compiling make_hlds. Over the weekend, I plan
to find out why. I would not be surprised by a smaller slowdown, but 10% is
more than I expected, given that most unifications and comparisons are of
primitives, which are handled the same in the two versions. OTOH,
--no-special-preds reduces the compiler executable from 5.6 Mb to 5.0 Mb.

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