[PATCH] D127202: [InlineFunction] Handle early exit during getUnderlyingObjects due to MaxLookup

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 24 03:44:25 PDT 2022


nikic added a comment.

I've landed https://github.com/llvm/llvm-project/commit/54eff7da3c6147451b0fd4defb1421db167dc9c6 and https://github.com/llvm/llvm-project/commit/e523baa664b7fc678aa1c0963980a70af161469d while looking into this, so please rebase over these.



================
Comment at: llvm/lib/Transforms/Utils/InlineFunction.cpp:1115
+          // enough to get the real underlying object.
+          if (!isIdentifiedObject(V))
+            MayAliasForUnidentify = true;
----------------
shchenz wrote:
> nikic wrote:
> > This looks overly aggressive to me, and probably loses most of the point of the PointerMayBeCapturedBefore check. We should be classifying objects into isIdentifiedObject and isEscapeSource, where we can use the capture-based logic for isEscapeSource. (It's currently static in BasicAliasAnalysis, but can be exported.)
> Thanks. Updated.
I think the basic logic here is now right. I still find the way the flags are set somewhat confusing though, especially that CanDeriveViaCapture is always set, even for non-escape-sources.

I think something like this would make the different cases clearer: https://gist.github.com/nikic/d900c8b2e901fc9c3ab1eb30650af9c3


================
Comment at: llvm/test/Transforms/Coroutines/coro-retcon-opaque-ptr.ll:38
-; CHECK-NEXT:    call void @print(i32 5), !noalias !0
-; CHECK-NEXT:    call void @print(i32 6), !noalias !3
 ; CHECK-NEXT:    ret i32 0
----------------
Do you know why these changes happen? (Just wondering, it looks harmless.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127202/new/

https://reviews.llvm.org/D127202



More information about the llvm-commits mailing list