[PATCH] Don't lower MIN_EXPR and MAX_EXPR [was Re: GCC Benchmarks (coybench), AMD64 and i686, 14 August 2004]
Paolo Bonzini
paolo.bonzini@polimi.it
Thu Aug 19 14:32:00 GMT 2004
> I've no problem with the lowering or not of MIN_EXPR, MAX_EXPR and
> ABS_EXPR, but it seems to me that the more fundamental problem is
> that we're failing to CSE the phi nodes themselves.
Yes. I know this is only a work around.
> For example, it would be nice to optimize
>
> x = a ? b : c;
> y = a ? b : c;
>
> into the equivalent
>
> x = a ? b : c;
> y = x;
Not only nice -- I think I would have expected it even before tree-SSA...
> Alas I'm not a tree-ssa expert but the above transformations would
> appear doable with GCC's current infrastructure.
I don't know. I'd expect that PRE/FRE do this, but these things are not
trivial with SSA because the basic blocks in the first phi node do not
dominate those in the second phi node. As far as I could understand,
SSA makes many optimizations easier, but they are still going to require
solving data flow equations, etc., unless only follow
dominator->dominated edges.
For example, in this case
if (a1 < 0)
z1 = a1 + b1;
else
z2 = b1;
z3 = PHI (z1, z2)
if (a1 < 0)
w1 = a1 + b1;
else
w2 = a1;
w3 = PHI (w1, w2)
You cannot simply transform "w1 = z1" in the assignment for w1 because
this does not respect SSA's dominance property (all defs must dominate
their uses).
mole's testcase is simpler but, in concrete terms, it looks like SSA
excels at handling complex nests of if's and while's more than at
optimizing adjacent ones. Again, I'm not sure if this is right, but
given this particular optimizer deficiency, it seems plausible.
Paolo
More information about the Gcc-patches
mailing list