[PATCH] D103492: [RS4GC] Treat inttoptr as base pointer

Thu Jun 3 09:35:53 PDT 2021

reames added a comment.

In D103492#2792357 <https://reviews.llvm.org/D103492#2792357>, @tolziplohu wrote:

> It tuns out the problem only occurs when addrspace(1) isn't specified as non-integral, because inttoptr instructions are ill-typed when it's non-integral. But when addrspace(1) isn't specified as non-integral, RewriteStatepointsForGC still assumes that it is, and that inttoptr isn't allowed.

Er, I think you've got a deeper issue here.  RS4GC is intended to lower from the abstract machine model to the physical machine model.  In the abstract machine model, references (i.e. gc pointers) *must* be non-integral.  You don't have to use address space 1 (there are code hooks to change that), but abstract machine model requires non-integral pointers for the address space being rewritten.

> If it's not non-integral, statepoints are only well-defined if the collector is non-moving, so inttoptr isn't a problem. So RS4GC only encounters inttoptr if GC pointers are integral, and thus the collector isn't moving (or the user is risking UB), and accepting it isn't a problem.

This is wrong.  The problem is that the optimizer can hide a pointer, not the relocation.

Example:
%i = ptrtoint %p
safepoint
%p2 = inttoptr %i
use (%p2)

In this example, the collector might collect the object pointed to by %p as it is not live over the safepoint.  This holds for both relocation and non-relocating collectors.

> Regardless, I still think there needs to be some way to represent an integer as a pointer even with moving collectors, for things like the polymorphism example I gave. In that case, it's not necessary for it to work with actual, valid pointers, only for integer -> pointer -> integer conversion to work, assuming nothing is done with the pointer in the middle and the collector doesn't move it. This is actually possible with non-integral pointers via an addrspacecast before ptrtoint and after inttoptr, which I believe is technically UB but works fine if RS4GC accepts it and the collector knows to ignore it.

This is a really really hard design problem.  I'm happy to discuss this offline, and I'm open to having a rule for handling inttoptr with explicit calls outs on the UB, but I'm worried you are misunderstanding the problem and are going to find yourself down a much deeper rabbit hole than you expect.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103492/new/

https://reviews.llvm.org/D103492