[PATCH] SCEVExpander incorrectly marks increment operations as no-wrap

Andrew Trick atrick at apple.com
Wed Feb 25 23:53:20 PST 2015


> On Feb 25, 2015, at 11:19 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
> 
>> SCEVExpander could have a mode that attempts to preserve flags, and a mode where it just always generates the sub. Or you can try to generate the sub whenever it doesn't lose the flags. However, I vote for keeping it simple and just always generating the add and letting InstCombine cleanup if it actually matters.
> 
> I agree -- I'll put up a patch for review shortly.
> 
>> Incidentally, are you more often relying on nsw/nuw to be inferred within SCEV, or are you relying more on your frontend to generate them in special situations?
> 
> All Java-level integer arithmetic gets lowered into
> potentially-wrapping operations, and it is up to scalar evolution to
> prove when overflow does not happen.

Sure, but there might be some implied arithmetic for addressing members. Anyway, it’s great that you don’t need to preserve those flags. That way they only exist within SCEV in order to prove properties about recurrences.

> Slight tangent:  I noticed is that LFTR will not happen for a loop
> with multiple exiting blocks.  Most of the interesting loops we
> generate have multiple exiting blocks due to range checks and null
> checks, so this may yet be another area where we end up missing some
> optimizations because of non-canonical IR.

Do you think LFTR is a canonicalization? Have you run across SCEV logic that depends on an exit test that checks equality? From what I can remember, LFTR mainly exists so that LSR can create a downward-counting IV. In fact, if that’s the only purpose, LFTR should really be moved to LSR.

-Andy

>> 
>> 
>> REPOSITORY
>>  rL LLVM
>> 
>> http://reviews.llvm.org/D7778
>> 
>> EMAIL PREFERENCES
>>  http://reviews.llvm.org/settings/panel/emailpreferences/
>> 
>> 





More information about the llvm-commits mailing list