[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