This is an archive of the discontinued LLVM Phabricator instance.

[LAA] Fix ICE with scAddExpr in forked pointers
ClosedPublic

Authored by huntergr on Aug 31 2022, 7:09 AM.

Details

Summary

The IR from https://github.com/llvm/llvm-project/issues/57368 results
in an assert firing when trying to create a runtime check for the
forked pointer. One of the forks is fine since it's loop invariant,
but the other is a scAddExpr (containing a scAddRecExpr, so not
invariant) when RtCheck::insert expects a scAddRecExpr.

This is a simple fix to just avoid forks which aren't AddRec or
loop invariant. We can allow it as a forked pointer later with
more work.

Diff Detail

Event Timeline

huntergr created this revision.Aug 31 2022, 7:09 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 31 2022, 7:09 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
huntergr requested review of this revision.Aug 31 2022, 7:09 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 31 2022, 7:09 AM
huntergr added inline comments.Aug 31 2022, 7:35 AM
llvm/test/Analysis/LoopAccessAnalysis/forked-pointers.ll
899

This concerns me a bit -- the lower bound is correct, but the upper bound seems wrong. But that isn't related to my forked pointers patch -- I get the same output if I comment out the forked pointer detection code entirely.

fhahn added inline comments.Aug 31 2022, 7:43 AM
llvm/test/Analysis/LoopAccessAnalysis/forked-pointers.ll
899

This is probably because PSE a predicate for this. The loop has an IV that start at 0 and we only exit if iv == 0. This can only happen if iv overflows AFAICT. But the IV increment is add nuw nsw i64 %indvars.iv.us1, 1, so if it overflows it is UB.

Can the issue be reproduced with a loop that doesn't have UB, e.g. replacing the existing exit check with something like cmp eq i64 %indvars.iv.next.us, %N?

925

The IR value names here seem a bit long which makes things a bit harder to read. It would probably be good to remove the naming prefixes/suffixes added be LLVM transforms (.e.g indvars, i.i., .us)

huntergr updated this revision to Diff 456964.Aug 31 2022, 8:14 AM

Simplified the value names in the test case to improve readability.

huntergr marked an inline comment as done.Aug 31 2022, 8:15 AM
huntergr added inline comments.
llvm/test/Analysis/LoopAccessAnalysis/forked-pointers.ll
899

You're right, thanks. I see (Low: %Base2 High: ((8 * %N) + %Base2)) if I add a parameter for iterations.

fhahn added inline comments.Sep 1 2022, 2:04 PM
llvm/test/Analysis/LoopAccessAnalysis/forked-pointers.ll
899

It would probably make the test easier to follow if the test would use the updated exit condition. It should still reproduce the AddRec issue I think.

huntergr updated this revision to Diff 458453.Sep 7 2022, 7:43 AM

Changed test to use a non-constant-zero loop limit to remove UB.

huntergr marked an inline comment as done.Sep 7 2022, 7:43 AM
fhahn accepted this revision.Sep 7 2022, 1:02 PM

LGTM, thanks, with a few additional small test case suggestions.

llvm/test/Analysis/LoopAccessAnalysis/forked-pointers.ll
928

Is the trunc & ext needed for the cash to reproduce? If not, it would be good to remove it.

929

Can you make the condition here a function argument? Not having the select being fold-able may make the test more robust in case SCEV gets extended to look through trivial selects.

This revision is now accepted and ready to land.Sep 7 2022, 1:02 PM
fhahn added a comment.Sep 20 2022, 6:55 AM

reverse ping?

This revision was automatically updated to reflect the committed changes.
huntergr added inline comments.Sep 21 2022, 2:31 AM
llvm/test/Analysis/LoopAccessAnalysis/forked-pointers.ll
928

No. We might be able to use different instructions, but without the zext at least we would have an AddRecExpr, which would just be folded.

929

No. I think SCEV already looks through the select at some point; if the condition isn't constant we don't see the crash.