The logic exposed by this patch via llvm::DetermineUseCaptureKind was
part of llvm::PointerMayBeCaptured. In the Attributor we want to keep
track of the work list items but still reuse the logic if a use might
capture a value. A follow up for the Attributor removes ~100 lines of
code and complexity while making future handling of simplified values
possible.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
LGTM
llvm/include/llvm/Analysis/CaptureTracking.h | ||
---|---|---|
119 | "the user" -> "the transitive uses"? We're inspecting the user either way. |
llvm/include/llvm/Analysis/CaptureTracking.h | ||
---|---|---|
113 | Hi, while PASSTHROUGH seems to be a good name for the enum value, it so happened, that it is also a macro defined in wingdi.h (which is included in windows.h). Can we consider renaming it or we should guard/undef the macro in the downstream? |
llvm/include/llvm/Analysis/CaptureTracking.h | ||
---|---|---|
113 | Rename it here and in all use sites. I guess we could add UCK_ ad prefix, or make it something like USER_MAY_CAPTURE. |
Hi, while PASSTHROUGH seems to be a good name for the enum value, it so happened, that it is also a macro defined in wingdi.h (which is included in windows.h). Can we consider renaming it or we should guard/undef the macro in the downstream?