This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Reassociation
- To: Gavin Romig-Koch <gavin at cygnus dot com>
- Subject: Re: Reassociation
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 17 Dec 1998 21:00:07 -0700
- cc: tprince at cat dot e-mail dot com, bosch at gnat dot com, burley at gnu dot org, egcs at cygnus dot com, hjstein at bfr dot co dot il, jbuck at Synopsys dot COM, moshier at mediaone dot net
- Reply-To: law at cygnus dot com
In message <13945.15741.725261.89997@cetus.cygnus.com>you write:
> 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.)
I was just throwing out one idea. Having the front end indicate which
expressions can be reassociated is another obvious approach.
I haven't through through either far enough to make an informed guess about
which would be better.
> 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-underflo
> w)?
I think it needs to be per expression. I don't know if we need to break it
into multiple "don't care about XYZ flags".
In any event, this isn't something we're likely to have soon. I'd like to
suggest we slow down this discussion -- it's generating a ton of mail about
something we may not have the time to do anytime soon.
jeff