[PATCH][RFA][PR tree-optimization/79095] Improve overflow test optimization and avoid invalid warnings

[Jeff Law]

On 01/27/2017 02:35 PM, Richard Biener wrote:
> On January 27, 2017 7:30:07 PM GMT+01:00, Jeff Law <law@redhat.com> wrote:
>> On 01/27/2017 05:08 AM, Richard Biener wrote:
>>> On Fri, Jan 27, 2017 at 10:02 AM, Marc Glisse <marc.glisse@inria.fr>
>> wrote:
>>>> On Thu, 26 Jan 2017, Jeff Law wrote:
>>>>
>>>>>> I assume this causes a regression for code like
>>>>>>
>>>>>> unsigned f(unsigned a){
>>>>>>   unsigned b=a+1;
>>>>>>   if(b<a)return 42;
>>>>>>   return b;
>>>>>> }
>>>>>
>>>>> Yes.  The transformation ruins the conversion into ADD_OVERFLOW for
>> the +-
>>>>> 1 case.  However, ISTM that we could potentially recover the
>> ADD_OVERFLOW in
>>>>> phi-opt.  It's a very simple pattern that would be presented to
>> phi-opt, so
>>>>> it might not be terrible to recover -- which has the advantage that
>> if a
>>>>> user wrote an optimized overflow test we'd be able to recover
>> ADD_OVERFLOW
>>>>> for it.
>>>>
>>>>
>>>> phi-opt is a bit surprising at first glance because there can be
>> overflow
>>>> checking without condition/PHI, but if it is convenient to catch
>> many
>>>> cases...
>>>
>>> Yeah, and it's still on my TODO to add some helpers exercising
>>> match.pd COND_EXPR
>>> patterns from PHI nodes and their controlling condition.
>> It turns out to be better to fix the existing machinery to detect
>> ADD_OVERFLOW in the transformed case than to add new detection to
>> phi-opt.
>>
>> The problem with improving the detection of ADD_OVERFLOW is that the
>> transformed test may allow the ADD/SUB to be sunk.  So by the time we
>> run the pass to detect ADD_OVERFLOW, the test and arithmetic may be in
>> different blocks -- ugh.
>>
>> The more I keep thinking about this the more I wonder if transforming
>> the conditional is just more of a headache than its worth -- the main
>> need here is to drive propagation of known constants into the THEN/ELSE
>>
>> clauses.  Transforming the conditional makes that easy for VRP & DOM to
>>
>> discover those constant and the transform is easy to write in match.pd.
>>
>> But we could just go back to discovering the case in VRP or DOM via
>> open-coding detection, then propagating the known constants without
>> transforming the conditional.
>
> Indeed we can do that.  And in fact with named patterns in match.pd you could even avoid the open-coding.
?!? Is there an example of this somewhere?

jeff