Patch for capture tracking broke
bootstrap of clang with -fstict-vtable-pointers
which resulted in debbugging nightmare. It was fixed
https://reviews.llvm.org/D46900 but as it turned
out, there were other parts like inliner (computing of
noalias metadata) that I found after bootstraping with enabled
assertions.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 18387 Build 18387: arc lint + arc unit
Event Timeline
llvm/lib/Analysis/BasicAliasAnalysis.cpp | ||
---|---|---|
135 | Makes sense, thanks |
Is there some general principle we can outline to describe where these updates are needed?
I am not sure how to do it right since I am not that familiar with this codebase. Maybe we can make function like
// This function can be used only for aliasing properties. You CAN'T use it to replace // one value with another! bool getArgumentAliasingToReturnedPointer(Function *F) { if (Value *RV = CS.getReturnedArgOperand()) return RV; if (CS.getIntrinsicID() == Intrinsic::launder_invariant_group) return CS.getArgOperand(0); return nullptr; }
And use it in the places that I modified. Unfortunately it will not change CaptureTracking, because it goes top-down instead of bottom-up.
How does it sound to you?
I think this refactoring makes sense. However...
And use it in the places that I modified.
What I want to know is: how did you decide what had to be modified? Did you just look for every place that handles returned arguments? If you had to describe to someone how to find the places that need modification, how would you do it? (because that's what we need in the comment).
Unfortunately it will not change CaptureTracking, because it goes top-down instead of bottom-up.
How does it sound to you?
Yes, I pretty much checked every place that uses CaptureTracking and looked for special handling of calls or uses of getUnerlyingObject.
Refactored code to getArgumentAliasingToReturnedPointer and added few comments.
Please check out isKnownNonZero, as I think it could also use getArgumentAliasingToReturnedPointer.
Some of these changes are required for correctness, right? For those, please specifically add a comment near those explaining why.
llvm/include/llvm/Analysis/ValueTracking.h | ||
---|---|---|
588 | Extra whitespace change? |
Of course, you should wait for an LGTM from someone more competent than me ;)
llvm/lib/Analysis/CaptureTracking.cpp | ||
---|---|---|
253 | nit: do not capture |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3388 | Why assert here? |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3388 | It is possible that this funciton would return nullptr if passed null CS, |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3388 | Can you add a info message into assert then? |
- use getArgumentAliasingToReturnedPointer as it does not change behavior
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3388 | sure, make sense |
llvm/lib/Analysis/BasicAliasAnalysis.cpp | ||
---|---|---|
435 | Please explain here *how* this keeps this in sync. There's no obvious use of CaptureTracking here. | |
llvm/lib/Analysis/ValueTracking.cpp | ||
3450 | Same here. Please explain how this helps to keep tings in sync with CaptureTracking. There's some implicit contract here between these functions that we need to document explicitly. |
llvm/lib/Analysis/BasicAliasAnalysis.cpp | ||
---|---|---|
435 | I updated the comment, but I have a new idea how to make it better. I will refactor the list of intrinsic to some other function, to make it always in sync. |
- small refactor
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3399 | Note that llvm.strip.invariant.group will be added in this patch |
llvm/lib/Analysis/BasicAliasAnalysis.cpp | ||
---|---|---|
435 | That's good, but doesn't explain why keeping these in sync is necessary for correctness. To put it another way, please explain what does wrong if these are not in sync. |
LGTM
This is still a bit convoluted, but I think that someone can now figure out what's going on from the comments. They also raise an interesting point of whether we should somehow separate out the capture-only-by-return case from the more-general case (although that's nothing to be addressed here).
Extra whitespace change?