[PATCH] D103492: [RS4GC] Treat inttoptr as base pointer
Sam Dirkswager via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jun 1 15:51:27 PDT 2021
tolziplohu added a comment.
Do you mean that it's unsound because inttoptr is undefined behavior for non-integral pointers? I understand why that's the case, but there needs to be some way to represent an integer as a pointer for things like the polymorphism example I gave. It's probably fine if it's not guaranteed to work with all non-integral pointers, and if pointer -> integer -> pointer is undefined; the only thing that's necessary there is integer -> pointer -> integer with no manipulation of the pointer in between.
I do have an example of current unsoundness - running `opt --instcombine` on this creates an inttoptr:
define i8 addrspace(1)* @test(i8 addrspace(1)* %0, i8 addrspace(1)* %1) gc "statepoint-example" {
entry:
call void @llvm.memcpy.p1i8.p1i8.i64(i8 addrspace(1)* align 8 %1, i8 addrspace(1)* align 8 %0, i64 8, i1 false)
%casted_load_slot = bitcast i8 addrspace(1)* %1 to i8 addrspace(1)* addrspace(1)*
%load = load i8 addrspace(1)*, i8 addrspace(1)* addrspace(1)* %casted_load_slot, align 8
ret i8 addrspace(1)* %load
}
; Function Attrs: argmemonly nounwind willreturn
declare void @llvm.memcpy.p1i8.p1i8.i64(i8 addrspace(1)* noalias nocapture writeonly, i8 addrspace(1)* noalias nocapture readonly, i64, i1 immarg) #0
attributes #0 = { argmemonly nounwind willreturn }
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D103492/new/
https://reviews.llvm.org/D103492
More information about the llvm-commits
mailing list