================
@@ -359,6 +359,11 @@ UseCaptureInfo llvm::DetermineUseCaptureKind(const Use &U,
const Value *Base) {
case Instruction::AddrSpaceCast:
// The original value is not captured via this if the new value isn't.
return UseCaptureInfo::passthrough();
+ case Instruction::PtrToAddr:
+ // FIXME: the following does not work as expected, so just assume address
+ // is always captured:
+ // return UseCaptureInfo(CaptureComponents::None,
CaptureComponents::Address);
----------------
nikic wrote:
I think this quote from LangRef answers your questions:
> However, we always consider direct inspection of the pointer address (e.g.
> using ptrtoint) to be location-independent. The following example is not
> considered a return-only capture, even though the ptrtoint ultimately only
> contributes to the return value:
>
> ```llvm
> @lookup = constant [4 x i8] [i8 0, i8 1, i8 2, i8 3]
>
> define ptr @f(ptr %a) {
> %a.addr = ptrtoint ptr %a to i64
> %mask = and i64 %a.addr, 3
> %gep = getelementptr i8, ptr @lookup, i64 %mask
> ret ptr %gep
> }
> ```
The same would also apply if you replace ptrtoint with ptrtoaddr.
Continuing recursive analysis after ptrtoaddr is possible, but we'd need logic
to do that correctly, which is not the same as the current pointer following
logic. So yes, `CaptureComponents::Address` is correct here.
https://github.com/llvm/llvm-project/pull/152221
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
