<div><div dir="auto">Adding some folks from Azul. </div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 30, 2019 at 4:00 PM Jake Ehrlich via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi All,<br><br>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.<br><br>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.<br><br>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.<br><br>So specifically the proposal is just the following<br>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.<br><br>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.<br><br>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?</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>