This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

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

From: Paolo Bonzini <bonzini at gnu dot org>
To: Richard Guenther <rguenther at suse dot de>
Cc: gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org
Date: Thu, 21 Feb 2008 11:16:28 +0100
Subject: Re: [PATCH][RFC] Optimize more with PAREN_EXPR
References: <Pine.LNX.4.64.0802211038540.5150@zhemvz.fhfr.qr>

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)

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.

Paolo

Follow-Ups:
- Re: [PATCH][RFC] Optimize more with PAREN_EXPR
  - From: Richard Guenther

References:
- [PATCH][RFC] Optimize more with PAREN_EXPR
  - From: Richard Guenther

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]