Re: [PATCH][RFC] Optimize more with PAREN_EXPR

[Richard Guenther <rguenther at suse dot de>]

On Thu, 21 Feb 2008, Paolo Bonzini wrote:

> 
> > To not need to adjust individual transformations I chose to extend
> > operand_equal_p to simply look through PAREN_EXPR, making it
> > treating x and ((x)) the same.  I think this is wrong, but this
> > was the easiest thing to do for experimenting.  Any different
> > opinion on that?  I don't think an existing transformation will
> > break because of this, though.
> 
> I am not sure.  An example:
> 
> ((a + b) + c) + (a + b + c)

Heh right.  Didn't think of this simple one ;)  Breaks for

 a + b + c + ((a + b) + c)

but not

 ((a + b) + c) + a + b + c

> you have to be sure to fold it to 2 * ((a + b) + c) with the parentheses
> inside.
> 
> I think a better design is to have a new operand_equal_p flag to see through
> PAREN_EXPRs.
> 
> Another useful helper function would go through op1 and op2 which are
> structurally equivalent except for PAREN_EXPRs, and make a tree with the
> strictest association.

Yeah, maybe

tree get_equal_operand (tree op0, tree op1)

returnig the "same" operand or NULL if op0 and op1 are not the same.

The question is how sophisticated you want to be.  For example

 (a + b + c) and (a + b) + c

could have ((a + b) + c) as "same" operand?

Of course you'd need to touch a whole lot of existing uses of
operand_equal_p to get a benefit.  I'll see to cover the easy
cases.

Thanks,
Richard.