<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Ok, so you’re saying you want it to be part of the llvm/llvm-project/tree/main/compiler-rt tree, but not part of the compiler_rt library itself, got it.<div class=""><br class=""></div><div class="">Does compiler-rt currently depend on LLVM libraries? Does this change the dependence graph of the llvm and compiler-rt subproject?</div><div class=""><br class=""></div><div class="">-Chris<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 19, 2021, at 10:31 AM, Lang Hames <<a href="mailto:lhames@gmail.com" class="">lhames@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><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">Arguments in favor are that the build requirements are very similar, and there are some conceptual parallels (the ORC runtime is providing implementations for entry points generated by the compiler and linker, among other things). On the other hand the implementations are all JIT specific, which is definitely different from everything else in compiler-rt.</blockquote><div dir="ltr" class=""><br class=""></div><div class="">After a night to think about it I think I'd rephrase this: <i class="">The ORC runtime is a JIT-specific compiler runtime library</i>. From a JIT developer's point of view it is an excellent fit for compiler-rt, and from a static compiler developer's point of view it's a non-entity, so just dead weight.</div><div class=""><br class=""></div><div class="">If compiler-rt were broken up then it would make sense to have the ORC runtime be a separate subproject and client of the common complier-rt build infrastructure. That would be the ideal solution. Until then I think compiler-rt seems like the best home for it -- making the ORC runtime its own subproject now would duplicate compiler-rt's build system only for us to have to reconcile it later (or worse, maintain the duplication indefinitely).</div><div class=""><br class=""></div><div class="">Petr, Eric -- Do you have a sense of how difficult it would be to lift compiler-rt's common build infrastructure out? Being new to compiler-rt I'm wary of tackling that, but if you think it'd be easy I'm happy to work with you to try to get it done.</div><div class=""><br class=""></div><div class="">-- Lang.</div><div class=""><br class=""></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 18, 2021 at 9:50 PM Lang Hames <<a href="mailto:lhames@gmail.com" class="">lhames@gmail.com</a>> wrote:<br class=""></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="ltr" class="">Hi Chris,<div class=""><br class=""></div><div class="">My understanding is that compiler-rt is an umbrella project that builds a number of libraries (builtins, asan, tsan, fuzzer, etc.), and my thought was that the ORC runtime could fit in as an addition to that set. Arguments in favor are that the build requirements are very similar, and there are some conceptual parallels (the ORC runtime is providing implementations for entry points generated by the compiler and linker, among other things). On the other hand the implementations are all JIT specific, which is definitely different from everything else in compiler-rt.</div><div class=""><br class=""></div><div class="">If not compiler-rt, is there anywhere else that you think this project would fit? Would it make sense to introduce it as a new top-level project?</div><div class=""><br class=""></div><div class="">-- Lang.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 18, 2021 at 9:08 PM Chris Lattner <<a href="mailto:clattner@nondot.org" target="_blank" class="">clattner@nondot.org</a>> wrote:<br class=""></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 style="word-wrap:break-word;line-break:after-white-space" class="">Hey Lang, <div class=""><br class=""></div><div class="">Is your goal here to make this part fo compiler_rt the generated library, or part of the subproject? This seems conceptually very different than compiler_rt (which was supposed to be entry points implicitly generated by the compiler). Should this be its “own thing”?</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Apr 17, 2021, at 1:51 PM, Lang Hames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class="">Hi All,<div class=""><br class=""></div><div class="">I've broken the compiler-rt cmake changes and new directories out of the ORC runtime prototype and posted them for review in <a href="https://reviews.llvm.org/D100711" target="_blank" class="">https://reviews.llvm.org/D100711</a>.</div><div class=""><br class=""></div><div class="">Most of this was adapted from xray's cmake files and project layout. I'm not a CMake expert, so I expect there's room for improvement here, but otherwise I'm hoping it's a pretty canonical "new compiler-rt library".</div><div class=""><br class=""></div><div class="">Kind Regards,<br class=""></div><div class="">Lang. </div></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 14, 2021 at 10:34 AM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank" class="">lhames@gmail.com</a>> wrote:<br class=""></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="ltr" class="">Hi All,<div class=""><br class=""></div><div class="">Petr -- since the ORC runtime's dependencies are similar to libFuzzer's, is there any reason not to land the ORC runtime in compiler-rt now and then break it out again later? If the compiler-rt refactor is likely to happen soon then it's worth waiting, otherwise I think landing it in compiler-rt sooner rather than later is the best option, so that any kinks in the integration can be worked out before any future compiler-rt refactor.</div><div class=""><br class=""></div><div class="">-- Lang.</div><div class=""><br class=""></div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 12, 2021 at 4:38 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank" class="">lhames@gmail.com</a>> wrote:<br class=""></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="ltr" class=""><div dir="ltr" class=""><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">From this it sounds like "convenient reusing of the build system" rather than "should be included in compiler-rt as a library"? If that's the case maybe making it clear or lifting the common build system support out might be maintainable without the "this is a runtime library for the system" sort of thing?</blockquote><div class=""><br class=""></div><div class="">Yeah. It sounds like in an ideal world we'd lift out the common build system support, then have a new set of sub-projects that re-use that generic build system.</div><div class=""><br class=""></div><div class="">Do you have any sense of how difficult it would be to lift out that common build system code? If that's relatively easy then maybe the right approach is to do that first, then land the ORC runtime. Otherwise the ORC runtime could go in to compiler-rt for now, then be split out with the rest of compiler-rt when it's broken up -- it doesn't require any meaningful changes to existing compiler-rt code, so it should be very easy to break back out again later.</div><div class=""><br class=""></div><div class="">-- Lang.</div><div class=""><br class=""></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 12, 2021 at 3:51 PM Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank" class="">echristo@gmail.com</a>> wrote:<br class=""></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="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 12, 2021 at 6:36 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank" class="">lhames@gmail.com</a>> wrote:<br class=""></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="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class="">Hi Petr,<div class=""><br class=""></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">I'd like to better understand the structure of the ORC runtime and its dependencies (both build and runtime). Does it use the C or C++ standard library? Does it depend on other parts of LLVM? Do you plan on reusing some of the existing compiler-rt libraries like sanitizer_common?</blockquote><div class=""><br class=""></div><div class="">The ORC runtime currently uses the C++ standard library.<br class=""></div><div class="">Since the ORC runtime needs to communicate with the LLVM ORC library it also currently uses some header-only includes from LLVM. It does not depend on any LLVM libraries. We could duplicate this code, but I'd prefer to share it if possible.</div><div class="">I have not used sanitizer_common, but some parts of it look like they may be useful.<br class=""></div><div class=""><br class=""></div><div class="">I gravitated towards implementing the ORC runtime in compiler-rt because I need to be able to write parts of it in platform-specific assembly (which compiler-rt supports), and because the runtime should be build for all targets, not just the host (which seems to be the standard way that compiler-rt is configured).</div><div class=""><br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">From this it sounds like "convenient reusing of the build system" rather than "should be included in compiler-rt as a library"? If that's the case maybe making it clear or lifting the common build system support out might be maintainable without the "this is a runtime library for the system" sort of thing?</div><div class=""><br class=""></div><div class="">-eric</div><div class=""> </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="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""></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">To give a bit more background on why I'm interested, compiler-rt has grown fairly organically this has been making the maintenance more and more difficult, at least from the build perspective. There are some runtimes that only use C, some that use C++, some that use C++ standard library. When building compiler-rt together with other runtimes like libc or libc++, it's difficult to pick up the right order which is why we have several entry points into compiler-rt's build system to build different subsets and that's been a maintenance headache.</blockquote><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"><br class=""></blockquote><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">I've been thinking about this quite a bit recently and I repeatedly came to the conclusion that compiler-rt would ideally be broken up into several subprojects, but that should probably be discussed as a separate topic. However, understanding the build and runtimes dependencies of the ORC runtime could help us decide whether it should be a part of compiler-rt or be a separate subproject.</blockquote><div class=""><br class=""></div><div class="">That makes sense to me. I think of the ORC runtime as a compiler-rt-style runtime with a libc++ dependency. In that sense I think it's similar to libFuzzer, and whatever solution we come up with for libFuzzer would probably also be applicable to the ORC runtime too.</div><div class=""><br class=""></div><div class="">-- Lang.</div></div></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 12, 2021 at 2:36 PM Petr Hosek <<a href="mailto:phosek@google.com" target="_blank" class="">phosek@google.com</a>> wrote:<br class=""></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="ltr" class=""><div class="">I'd like to better understand the structure of the ORC runtime and its dependencies (both build and runtime). Does it use the C or C++ standard library? Does it depend on other parts of LLVM? Do you plan on reusing some of the existing compiler-rt libraries like sanitizer_common?</div><div class=""><br class=""></div><div class="">To give a bit more background on why I'm interested, compiler-rt has grown fairly organically this has been making the maintenance more and more difficult, at least from the build perspective. There are some runtimes that only use C, some that use C++, some that use C++ standard library. When building compiler-rt together with other runtimes like libc or libc++, it's difficult to pick up the right order which is why we have several entry points into compiler-rt's build system to build different subsets and that's been a maintenance headache.</div><div class=""><br class=""></div><div class="">I've been thinking about this quite a bit recently and I repeatedly came to the conclusion that compiler-rt would ideally be broken up into several subprojects, but that should probably be discussed as a separate topic. However, understanding the build and runtimes dependencies of the ORC runtime could help us decide whether it should be a part of compiler-rt or be a separate subproject.</div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 12, 2021 at 12:26 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank" class="">lhames@gmail.com</a>> wrote:<br class=""></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="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class="">Hi All,<br class=""><div class=""><br class=""></div><div class="">I'd like to add the ORC runtime library (preview available at <a href="https://github.com/lhames/llvm-project/tree/orc-runtime-preview" target="_blank" class="">https://github.com/lhames/llvm-project/tree/orc-runtime-preview</a>) to compiler-rt.</div><div class=""><br class=""></div><div class="">Background:</div><div class=""><br class=""></div><div class="">ORC, like MCJIT, can link JIT'd code either into the current process ("in-process" mode) or into a remote executor process ("cross-process" mode). Some JIT features require support code in the executor process, but the existing ORC libraries are only linked into the JIT process. This has made cross-process mode support for those features (which include static initializers, thread local variables, exception handling, and others) awkward or impractical to implement. The ORC runtime library aims to provide the necessary support code in a form that is loadable by the JIT itself, which should allow these features to work uniformly in both modes.</div><div class=""><br class=""></div><div class="">My prototype branch of the ORC runtime (available at <a href="https://github.com/lhames/llvm-project/tree/orc-runtime-preview" target="_blank" class="">https://github.com/lhames/llvm-project/tree/orc-runtime-preview</a>) has advanced to the point where it can provide uniform support for static initializers, destructors, exceptions, thread locals, and language registration for Objective C and Swift code. This support is all MachO/Darwin only so far, but should be easily adaptable for ELF/Linux/BSD support.</div><div class=""><br class=""></div><div class="">Proposal:</div><div class=""><br class=""></div><div class="">The proof of concept implementation has been very successful, so I would like to move future development to the LLVM main branch so that others can benefit from this.</div><div class=""><br class=""></div><div class="">Before I start posting patches, though:</div><div class=""><br class=""></div><div class="">Does anyone see any problems with including this in compiler-rt?</div><div class=""><br class=""></div><div class="">Does anyone think that there is a more reasonable home for the ORC runtime within the llvm-project? I considered LLVM itself, or a new top-level project, but neither seemed as natural a fit as compiler-rt.</div><div class=""><br class=""></div><div class="">Finally, if everyone is happy for it to be included in principle, are there any volunteers to review ORC runtime patches?</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Lang.</div></div></div></div></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div>
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>