Re: [PATCH] Fix multiply-add regressions after expand-from-SSA

[Adam Nemet <anemet at caviumnetworks dot com>]

Michael Matz writes:
> On Thu, 30 Apr 2009, Adam Nemet wrote:
> > > I think we should start to _not_ re-build trees here, but instead of
> > 
> > I am not rebuilding any tree here, just as operands are looked at I look 
> > at the TER expression in available.  Maybe the name of the helper is 
> > wrong.  I don't mean subsitute as in walking the tree and substituting 
> > subtrees but as in return the original expr or subsitute it with 
> > something "better".
> 
> The overall plan should be to get rid of rebuilding trees, so your current 
> helper would be a step in the wrong direction.  Richard showed the IMO 
> right way to solve this, instead of explicitely building trees return the 
> gimple statements and decompose them at the point where you need the 
> parts, i.e. in expand itself.
> 
> That at least followed also my ideas how to implement something similar to 
> TER with expand-from-SSA.

I see now.  To be honest, I just took the code from 'case SSA_NAME:' which is
probably something that was added now?

> On that topic it would also be very intersting to know other cases where 
> TER really helped.  Widening mult is one case, but there only if there's a 
> single use chain, so it would be strictly more powerful to implement that 
> transformation on gimple itself, instead of in expand.
> 
> In an ideal world we would get rid of TER altogether, that's why knowing 
> which cases are currently really helped by it is useful.

But it seems that the complexity comes from the fact that you either map all
RTL expanders to tree codes (maybe that's already the case) or you would have
to be able to look at the expression trees at expansion time which is not as
easy since we're no longer in SSA.  BTW, isn't the name expand-from-SSA
misleading or am I still missing something?

Adam