On Fri, Nov 04, 2016 at 01:54:20PM +0100, Richard Biener wrote: > On Fri, Nov 4, 2016 at 12:08 PM, Dominik Vogt <v...@linux.vnet.ibm.com> wrote: > > On Fri, Nov 04, 2016 at 09:47:26AM +0100, Richard Biener wrote: > >> On Thu, Nov 3, 2016 at 4:03 PM, Dominik Vogt <v...@linux.vnet.ibm.com> > >> wrote: > >> > Is VRP the right pass to do this optimisation or should a later > >> > pass rather attempt to eliminate the new use of b_5 instead? Uli > >> > has brought up the idea a mini "sign extend elimination" pass that > >> > checks if the result of a sign extend could be replaced by the > >> > original quantity in all places, and if so, eliminate the ssa > >> > name. (I guess that won't help with the above code because l is > >> > used also as a function argument.) How could a sensible approach > >> > to deal with the situation look like? > >> > >> We run into this kind of situation regularly and for general foldings > >> in match.pd we settled with single_use () even though it is not perfect. > >> Note the usual complaint is not extra extension instructions but > >> the increase of register pressure. > >> > >> This is because it is hard to do better when you are doing local > >> optimization. > >> > >> As for the question on whether VRP is the right pass to do this the > >> answer is two-fold -- VRP has the most precise range information. > >> But the folding itself should be moved to generic code and use > >> get_range_info (). > > > > All right, is this a sensible approach then? > > Yes. > > > 1. Using has_single_use as in the experimental patch is good > > enough (provided further testing does not show serious > > regressions). > > I'd approve that, yes. > > > 2. Rip the whole top level if-block from simplify_cond_using_ranges(). > > 3. Translate that code to match.pd syntax. > > Might be some work but yes, that's also desired (you'd lose the ability > to emit the warnings though).
Could you give me a match-pd-hint please? We now have something like this: (simplify (cond (gt SSA_NAME@0 INTEGER_CST@1) @2 @3) (if (... many conditions ...) (cond (gt ... ...) @2 @3)) The generated code ends up in gimple_simplify_COND_EXPR, but when gimple_simplify is actually called, it goes through the GIMPLE_COND case and calls gimple_resimplify2(..., GT, ...) and there it tries gimple_simplify_GT_EXPR(), peeling of the (cond ...), i.e. it never tries the generated code. There is another pattern in match.pd that uses a (cond ...) as the first operand, and I do not understand how this works. Should we just use "(gt SSA_NAME@0 INTEGER_CST@1)" as the first operand instead, and wouldn't this pattern be too general that way? Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany
