Re: Reassociation

[Gavin Romig-Koch <gavin at cygnus dot com>]

Jeffrey A Law writes:
 > The obvious way to do that in this case is:
 > 
 > 	* Introduce the concept of parens into the tree nodes for
 > 	  expressions.
 > 	* Honor parens and perform no associations across them.
 > 
 > 	* If a language does not allow reassociations, then it can make the
 > 	  implicit parents explicit in the tree structure.

While I agree that the front end needs a way to tell the backend
about what it can and can't optimize, I'm not sure parens in the
tree are the best way to do this.  (I've not been able to think this
completely through, and so it may be bunk, but I wanted to say something
before I forgot.)

If an arithmatic operation can't be reassociated using the mathimatical
reassociation rules, it's because of the possibilty of overflow, or
underflow, or div-by-zero (are their other?).  Collectively let me
call these side-effects (though perhaps these aren't necessarly the
same as C "side-effects").

If an operation can be reassociated, it's either because the front end
doesn't care about the effects of these side-effects, or because the
backend can determine that side-effects won't happen for a particular
operation, perhaps because of the operation and its operators, or 
perhaps because the architecture your compiling for doesn't detect
these side-effects.

So, rather than have the front end insert parens in the tree to
prevent reassociation, it would be better to have a way for the
front end to tell the back end wether or not it cares about
side-effect for a particular operation.

What's not clear to me is whether this "dont-care-about-side-effects"
flag needs to be specified per individual operation, or per function,
or per frontend, or per operation type?  Do we need separate flags
for each kind of side effect (care-about-overflow, dont-care-about-underflow)?

                                        -gavin...