This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Improve ability of PRE to detect redundancies
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 26 Nov 2004 10:38:28 -0500
- Subject: Re: [PATCH]: Improve ability of PRE to detect redundancies
- References: <Pine.LNX.email@example.com>
> How about "x + 0", "x << 0" and "x * 1" being equivalent to "x"?
> I only enquire as I expect that ultimately fold_binary_to_constant
> will become functionally equivalent to a call to "fold" followed
> by a CONSTANT_P test. At that time the only benefit of the
> fold_foo_to_constant APIs will be that unlike fold, it avoids
> constructing a tree node just to test whether something can be
> simplified. In your example, you already have the tree constructed,
> so fold is more appropriate.
Okeydokey, then i'll change it :)
> You'll notice that in tree-ssa-cpp.c there are far more calls to
> fold() than there are to fold_foo_to_constant() which are only
> used when a tree hasn't yet been constructed, which avoids the
> potential garbage generation of "fold (buildN (...))".
> Of course, there's nothing incorrect with your patch, I'm just
> trying to describe some "rules of thumb" for which of fold-const.c's
> interfaces is most appropriate and to discover whether this case
> is a valid exception.
It'd be nice if this was documented somewhere, maybe at the top of
I actually originally had it using fold, and one of the other people i
had look at the patch before i submitted it told me to switch because
fold generated too much garbage.
Not having looked at the internals of fold vs fold_x_to_constant in a
while, I simply believed them. :).
> Things will likely become even more confusing
> for 4.x with the probable addition of fold_unary, fold_binary and
> fold_ternary, and their siblings fold_build1, fold_build2 and
> > As for SPEC, I just ran the numbers, i never did real analysis of why it
> > wasn't improving them. I only did this because there was other real
> > code out there that this should improve. :)
> To support Dan's and Steve's request that this at least be considered
> for 4.0, this patch allows GCC to perform a class of optimization that
> competing commercial compilers have done for years but until now has
> been impossible for GCC.
Not that i don't appreciate the support, and that this isn't allowing us
to perform another class of optimizations that we couldn't before
(partial constant propagatin is one of them), but i just wanted to point
out that in your case, you might be thinking of the forward store motion
patch, which optimizes
int foo(int a, int b, int c)
int x = a * b;
return c ? x : a;
into the equivalent of:
int foo(int a, int b, int c)
return a * b;
(IE sinking the x = a * b so that it's only executed when we return x)
This catches some of that, but only in the reverse direction.
The forward store motion patch will be submitted for 4.1.
Just wanted to make sure you aren't accidently throwing your support for
something that doesn't do what you think it does. :)
> Perhaps bootstrap and regression testing on a few more platforms
> wouldn't hurt?
I've bootstrapped and regtested it on powerpc-darwin and ppc64-linux.
These are the only other platforms i've got lying around :)