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

[Geoff Berry via llvm-dev]

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.

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:

for.body.i:
   %i.07.i = phi i32 [ %inc.i, %for.body.i ], [ 0, %for.body.i.preheader ]
   %idxprom.i = zext i32 %i.07.i to i64
   %arrayidx.i = getelementptr inbounds i32, i32* %rot, i64 %idxprom.i
   %0 = load i32, i32* %arrayidx.i
   %inc.i = add i32 %i.07.i, 1
   %cmp.i = icmp ult i32 %inc.i, %size
   br i1 %cmp.i, label %for.body.i, label %do_bwe.exit


-- 
Geoff Berry
Employee of Qualcomm Datacenter Technologies, Inc.
  Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the Code 
Aurora Forum, a Linux Foundation Collaborative Project.