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

[Bernd Edlinger <bernd dot edlinger at hotmail dot de>]

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

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?