[PING] [PATCH] PR58143/58227 wrong code at -O3

[Richard Biener]

On Sun, Oct 6, 2013 at 2:22 PM, Bernd Edlinger
<bernd.edlinger@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.edlinger@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?