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] |

*From*: Jeff Law <law at redhat dot com>*To*: Richard Biener <rguenther at suse dot de>, Sebastian Pop <sebpop at gmail dot com>*Cc*: gcc-patches at gcc dot gnu dot org, marc dot glisse at inria dot fr*Date*: Wed, 22 Oct 2014 14:40:48 -0600*Subject*: Re: [PATCH][0/n] Merge from match-and-simplify*Authentication-results*: sourceware.org; auth=none*References*: <alpine dot LSU dot 2 dot 11 dot 1410151450430 dot 20733 at zhemvz dot fhfr dot qr> <20141016203852 dot GB29134 at f1 dot c dot bardezibar dot internal> <alpine dot LSU dot 2 dot 11 dot 1410170951450 dot 9891 at zhemvz dot fhfr dot qr> <20141017163558 dot GD29134 at f1 dot c dot bardezibar dot internal> <20141017182811 dot GA14499 at f1 dot c dot bardezibar dot internal> <alpine dot LSU dot 2 dot 11 dot 1410201329030 dot 9891 at zhemvz dot fhfr dot qr>

On 10/20/14 05:42, Richard Biener wrote:

That was a conscious decision and the idea was that the caller should do this via its lattice valueization function which could look like tree valueize (tree t) { if (TREE_CODE (t) == SSA_NAME && !has_single_use (t)) return NULL_TREE; return t; } But of course doing that unconditionally would also pessimize code. Generally we'd like to avoid un-CSEing stuff in a way that cannot be CSEd again. That's a more complex condition than what can be implemented with has_single_use. You might also consider a stmt doing a_1 + a_1 where a_1 has two uses now.

I thought about doing all simplifications first without committing any simplified sequence to the IL, then scanning over the result, pruning out cases that end up pessimizing code (how exactly isn't yet clear to me). So I'm not sure what we want to do here now. I don't very much like doing things explicitely in the pattern description (nor using the "has_single_use" predicate). I suppose for the gimple_build () stuff we could restrict simplifications to the expression we are building (not simplifying with SSA defs in the IL), more exactly mimicing fold_buildN behavior. I suppose for forwprop we could use the above valueize hook (but then regress because not all patterns as implemented in forwprop guard their def stmt lookup with has_single_use...). Any opinion on this? Any idea of a "simple" cost function if you have the functions IL before and after simplifications (but without any DCE/CSE applied)?

Maybe you then look at the more speculative cases... jeff

**References**:**[PATCH][0/n] Merge from match-and-simplify***From:*Richard Biener

**Re: [PATCH][0/n] Merge from match-and-simplify***From:*Sebastian Pop

**Re: [PATCH][0/n] Merge from match-and-simplify***From:*Richard Biener

**Re: [PATCH][0/n] Merge from match-and-simplify***From:*Sebastian Pop

**Re: [PATCH][0/n] Merge from match-and-simplify***From:*Sebastian Pop

**Re: [PATCH][0/n] Merge from match-and-simplify***From:*Richard Biener

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |