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

[Sanjoy Das via llvm-dev]

Adding some folks from Azul.

On Mon, Sep 30, 2019 at 4:00 PM Jake Ehrlich via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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?
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190930/d1987578/attachment.html>