On Sun, Oct 6, 2013 at 2:22 PM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > Ping! > > > How I should proceed with this patch, is it OK? > > The latest version was posted at: > http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00234.html
I have now attached a quick draft of a patch that rewrites the moved stmts to not exhibit possibly undefined signed overflow. Richard. > Thanks, > Bernd. > >> >> ping... >> >> On Wed, 4 Sep 2013 18:45:39, Bernd Edlinger wrote: >>> >>> On Tue, 3 Sep 2013 12:31:50, Richard Biener wrote: >>>> On Fri, Aug 30, 2013 at 6:43 PM, Bernd Edlinger >>>> <bernd.edlin...@hotmail.de> wrote: >>>>> Now I think this is good opportunity for a simple heuristic: >>>>> >>>>> If a statement is at loop level 1 we can move it out of the loop, >>>>> regardless of the fact, that it may invoke undefined behavior, because if >>>>> it is >>>>> moved then out of any loops, and thus it cannot be an induction variable >>>>> and >>>>> cause problems with aggressive loop optimizations later. >>>> >>>> VRP can still cause wrong-code issues (it's probably hard to generate a >>>> testcase though). Also a less conservative check would be to see >>>> whether we hoist _into_ loop level 0 (though we cannot check that at >>>> the point where you placed the check). >>> >>> Well, then I should better revert this heuristic again. >>> >>>>> Only statements with possible undefined behavior in nested loops can >>>>> become >>>>> induction variable if lim moves them from one loop into an outer loop. >>>>> >>>>> Therefore with extremely much luck the test case will pass unmodified. >>>>> I tried it, and the patch passes bootstrap and causes zero regressions >>>>> with this heuristic. >>>>> >>>>> Ok for trunk now? >>>> >>>> Jakub mentioned another possibility - make sure the moved expression >>>> does not invoke undefined behavior by computing in an unsigned type. >>> >>> That is a possibility, but on the other hand, that would obscure the >>> undefined >>> behavior and thus prevent other possible optimizations later. >>> >>> Another possibility would be to move the statement together with the >>> enclosing if-statement, thus really preserving the execution. >>> >>>> That said, for the sake of backporting we need a patch as simple as >>>> possible - so it would be interesting to see whether the patch without >>>> the loop 1 heuristic has any effect on say SPEC CPU 2006 performance. >>> >>> I do not have access to that test, but on the dhrystone benchmark this patch >>> has no influence whatsoever. >>> >>> Attached you'll find the latest version of my patch without the heuristic. >>> Bootstrapped on i686-pc-linux-gnu and regression tested again. >>> >>> Ok for trunk and 4.8 branch?