[llvm-dev] Proposal for llvm.experimental.gc intrinsics for inttoptr and ptrtoint

[Jake Ehrlich via llvm-dev]

Hi All,

I'm working on a project converting Dart to llvm. Dart uses a relocating GC
but additionally uses pointer tagging. The first bit of a pointer is a tag.
For integers a '0' bit is used and for pointers to objects a '1' bit is
used. V8 apparently uses a similar technique. Generated code may need to
check which bit is used when this information isn't statically known.
Additionally a function might have a parameter which might be of a dynamic
type so it might either pass an object or an integer for the same parameter
meaning that this parameter type has to be of a single type in the llvm IR.

I'd like to make use of the existing llvm.experimental.gc.statepoint
intrinsics but they strictly use non-integral types. This is required to
stop certain optimizations from making optimizations that conflict with
finding base pointers.

After speaking about this (primarily with Sanjoy Das) and gathering the set
of issues involved it seems it might be possible to resolve this by adding
two new intrinsics that mirror inttoptr and ptrtoint:
llvm.experimental.gc.inttoptr and llvm.experimental.gc.ptrtoint. These will
be opaque to all existing abstractions. An additional pass would be added
as well that would lower these versions of inttoptr and ptrtoint to their
standard forms. When this pass is added after other optimizations it should
in theory be safe. Potentially safe optimizations might be possible to
perform after this point but it isn't clear what optimizations would
actually be both useful and safe at this point. The user of such a pass is
responsible for not applying this pass before any optimizations that might
alter the representation of a pointer in an invalid manner.

So specifically the proposal is just the following
1) Add llvm.experimental.gc.inttoptr and llvm.experimental.gc.ptrtoint as
opaque "semanticless" intrinsic calls. They will be defined as `IntrNoMem`
operations since they won't ever be lowered to anything that may perform
any memory operations.

2) Add a pass LowerOpaqueIntergalPointerOps to perform the specified
lowering in order to allow these intrinsics to be compiled to code. Use of
these intrinsics without using this lowering steps will fail in code
generation since these intrinsics will not participate in code generation.

Does this seem like a sound approach? Does this seem like an acceptable way
forward to the community? What tweaks or alterations would people prefer?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190930/69d5ea9e/attachment.html>