This is the mail archive of the gcc@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: [RFC] Meta-description for tree and gimple folding

From: Marc Glisse <marc dot glisse at inria dot fr>
To: Richard Biener <rguenther at suse dot de>
Cc: gcc at gcc dot gnu dot org
Date: Tue, 11 Mar 2014 22:28:01 +0100 (CET)
Subject: Re: [RFC] Meta-description for tree and gimple folding
Authentication-results: sourceware.org; auth=none
References: <alpine dot LSU dot 2 dot 11 dot 1402271509470 dot 27942 at zhemvz dot fhfr dot qr> <alpine dot DEB dot 2 dot 10 dot 1402280938290 dot 3586 at laptop-mg dot saclay dot inria dot fr> <alpine dot LSU dot 2 dot 11 dot 1403031150210 dot 11121 at zhemvz dot fhfr dot qr>

On Mon, 3 Mar 2014, Richard Biener wrote:

How do you handle a
transformation that currently tries to recursively fold something else and
does the main transformation only if that simplified?


And doesn't do the other folding (because it's not in the IL literally?)?
Similar to the cst without overflow case, by writing custom C code
and allowing that to signal failure.

Note that for this kind of simplification, it can be inconvenient to havecanonicalization included with the "real" simplifications. Imagine I amlooking at (x?3:5)+y. If 3+y "simplifies" to y+3 and 5+y "simplifies" toy+5, then it looks worth it to replace the expression with x?y+3:(y+5).

Would there be a convenient way to separate them, so it can tell me that3+y should be replaced with y+3 but that it is not a simplification?


--
Marc Glisse

Follow-Ups:
- Re: [RFC] Meta-description for tree and gimple folding
  - From: Richard Biener

References:
- Re: [RFC] Meta-description for tree and gimple folding
  - From: Richard Biener

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