Re: [tree-ssa]: Invalid GIMPLE generated by C++ front end

[law at redhat dot com]

In message <wvl3cf192mm.fsf@prospero.boston.redhat.com>, Jason Merrill writes:
 >On Fri, 12 Sep 2003 13:49:30 -0600, law@redhat.com wrote:
 >
 >> In message <wvlsmo5nuuv.fsf@prospero.boston.redhat.com>, Jason Merrill writ
 >es:
 >>  >But your comment brings up the possibility that other passes will want to
 >>  >be able to check whether or not a transformation leaves the code in gimpl
 >e
 >>  >form.  Is this what you need?  If so, would calling back into gimplify_ex
 >pr
 >>  >be a reasonable alternative (if it worked)?
 >
 >> I'm certainly starting to see where that kind of capability would be useful
 >.
 >
 >For what sorts of things?

For example, let's say I have the following statements

a = x OP const1;
b = a OP const2;


If OP associates, then you can generate the following expression
  
  (x OP const1) OP const2

Then you want to pass that off to fold to try and simplify it.


Fold returns some value -- if the resulting value is a valid gimple
expression then we can transform those statements into

a = x OP const1;
b = <fold's return value, probably x OP const3>

Which in turn may allow us to remove the first statement since we've
removed a use of "a".  This happens quite often. 


Another example

x = a - b;
y = -x;

You want to generate - (a - b) and pass that to the folder which may
return either - (a - b) -- which is not gimple and uninteresting, or
it may return (b - a), which is interesting because we get to rewrite
the second statement as

x = a - b;
y = b - a;

And we may get to remove the x = a - b statement.


This can be done very easily within the dominator optimizer framework, and
in some ways it gives us a global combiner for trees.  It's also one of the
very few things left that cse does that our dominator optimizer doesn't
currently do :-)

The whole point is if the result of fold isn't a valid gimple expression,
then there's no optimization to perform.

jeff