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

Geoff Berry via llvm-dev llvm-dev at lists.llvm.org
Tue Aug 8 10:22:24 PDT 2017

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 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.

More information about the llvm-dev mailing list