<div dir="ltr"><div>What you are proposing sounds legal, and can probably be represented with the stackmaps. You will probably need to write your own code to parse the stackmaps and translate them to your GC implementation, as it sounds different from details of the reference implementation however. (Speaking as a JuliaLang developer, that does not use stackmaps, but considered them for integrating with our GC. We use non-integral pointers, then locate and trace those after optimizations to locate the GC pointers precisely)</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 8, 2021 at 4:48 PM Dwight Guth 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto">I am the developer of a compiler frontend that generates llvm IR. The language is garbage collected, but currently doesn't have any support for stack maps yet, which severely limits the places where garbage collection can occur.<div dir="auto"><br></div><div dir="auto">I would like to fix this, and am familiar with the documents online relating to gc strategies and statepoints in llvm. However, it seems much of the support for state points is dependent on the assumption that references are never passed to unmanaged functions, and you never have a pointer that might be garbage collected, or might not be, and you don't know at compile time.</div><div dir="auto"><br></div><div dir="auto">Our language violates both of these constraints. There are certain built in functions in the language that are implemented in c++ and passed direct pointers to garbage collected values (although garbage collection will never occur during these functions). There are also some types for which some constants are allocated statically in the data segment, and other non-constant values are allocated on the heap. Dereferencing the pointer can tell me which is which. Finally, some values of pointer type actually contain integer data, making use of the fact that all real pointers in our language are aligned, a la ocaml.</div><div dir="auto"><br></div><div dir="auto">Bearing these things in mind, what would I need to do in order to be able to use the llvm statepoint functionality to generate stack maps? Is it even practical to do so given the current code?</div></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>