[llvm-dev] [ScalarEvolution][SCEV] no-wrap flags dependent on order of getSCEV() calls

[Friedman, Eli via llvm-dev]

On 8/8/2017 10:22 AM, Geoff Berry via llvm-dev wrote:
> Hi all,
>
> I'm looking into resolving a FIXME in the LoopDataPrefetch (and 
> FalkorMarkStridedAccesses) pass by marking both of these passes as 
> preserving the ScalarEvolution analysis.  Unfortunately, when this 
> change is made, LSR will generate different code.  One of the root 
> causes seems to be that SCEV will return different nsw/nuw flags for 
> the same Value, depending on what order the SCEVs are computed, due to 
> the fact that the SCEV object unique-ing doesn't take the nsw/nuw 
> flags into account.  Since LoopDataPrefetch computes SCEVs in a 
> different order than LSR, the nsw/nuw flags seen by LSR will differ 
> based on whether the SCEVs are preserved from LoopDataPrefetch.
>
> I believe this issue has been discussed before, but I just wanted to 
> check if this is indeed the current expected behavior, and if anyone 
> has any plans/ideas for addressing this issue.

The general issue that SCEV nsw is weird is known... see, for example 
https://bugs.llvm.org/show_bug.cgi?id=23527.

> For reference, below is a reduced loop where this problem occurs.  The 
> SCEV for %i.07.i will have <nuw> or not depending on whether 
> %idxprom.i was computed before it:

%idxprom.i, the zext?  I'm not sure how you're getting that particular 
effect.  ScalarEvolution::getSCEV for a zext immediately calls getSCEV 
on its operand.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project