This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Reassociation
- To: moshier at mediaone dot net
- Subject: Re: Reassociation
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 17 Dec 1998 20:55:58 -0700
- cc: Gavin Romig-Koch <gavin at cygnus dot com>, 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
- Reply-To: law at cygnus dot com
In message <Pine.LNX.4.05.9812171311060.31450-100000@moshier.ne.mediaone.net>
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.)
>
> Yes, currently this is analyzed at rtl level in cse.c, which already
> knows all about the associative law. If you look at the rtl dumps for
> a*b*c*d versus (a*b)*(c*d) you can see they to have a distinctive
> character that might be detected the same way cse.c detects other
> situations. So I think you're probably right that tree level
> structures do not have to be involved.
The tree structures do need to get involved at some point.
Some languages (ie fortran) allow reassociation as long as we honor
paren boundaries. We need some way to find those boundaries. How do
you suggest we find them?
See fold-const.c It does most of the same transformations on trees that
cse.c is doing on RTL.
jeff