[m-dev.] diff: fix switches in IL

Fergus Henderson fjh at cs.mu.OZ.AU
Fri Nov 10 22:22:34 AEDT 2000


On 10-Nov-2000, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> I think it's a really dumb idea to have *any* unop operate on the
> enclosing operator (although in C syntax it does this indirectly).

Agreed.

> unsigned as an unary operator could have the property of making the *enclosed*
> operation an unsigned variant of that operation.
>
> 	{ InRange = unop(unsigned, 
> 			binop(<=, Index, const(int_const(Difference)))) },

I think your proposal suffers from similar problems to the original
cast_to_unsigned.  For example, if we write an optimization pass on
the MLDS that does constant folding, it will need to treat rvals that
are contained inside an `unsigned' unop specially.  Also mlds_to_c.m
would need lots of special cases to handle such an operator.

If we're going to do something like that, I'd prefer to put the annotation on
the operator itself, rather than in an enclosing rval:

 	{ InRange = binop(unsigned(<=), Index, const(int_const(Difference)))) },

However, I think it would probably be simpler to just make that

 	{ InRange = binop(unsigned_le, Index, const(int_const(Difference)))) },

I think I'll go with that approach.

We can revisit this if we add more general support for an `unsigned' type
in the Mercury standard library.

> cast_to_unsigned could be banned from MLDS altogether.

Yes, definitely.

It would be nice to ban it from the LLDS too and get rid of it entirely.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- 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
--------------------------------------------------------------------------



More information about the developers mailing list