<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 4 Oct 2019 at 03:50, Leonard Chan 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:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>At some time in the near future we would like to allow for Rust to use the new PM. As I understand it, Rust uses LLVM through the stable LLVM C API, which currently only provides an interface to the legacy PM. We wanted to ask what people think about how we should go about exposing the new PM through this API. We can think of 3 possibilities for now:</div></div></blockquote><div><br></div><div>Hi Leo,</div><div><br></div><div>I agree that increasing coverage of the stable C API (especially for such essentials as the new PM) is a worthwhile goal that will benefit various projects using LLVM.</div><div><br></div><div>About Rust specifically though, note that we're not restricted to the C API. Whenever we need something that isn't part of the C API (which is common), we just create our own bindings for it, i.e., write some C++ code that wraps whatever we need in a C API (see the src/rustllvm directory). It also seems unlikely Rust's use cases can be fully served by a C API in the near term, we already have substantial amounts of custom C++ code interacting with the legacy PM to do things not available in the C API (e.g. driving ThinLTO) and this customization need won't go away with the PM switch.</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Regardless, more C API coverage is still nice for Rust, and will be a much bigger enabler for other projects that don't have their own bindings to fill the gaps.<br></div><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>1) Just replace the API to expose the new PM instead of the legacy one.</div><div><br></div><div>I imagine we wouldn't want to do this since it would be a pretty sudden change and there wouldn't be new PM equivalents for the Initialize/FinalizeFunctionPassManager functions.</div><div><br></div><div>2) Add a new interface that exposes the new PM while still keeping the current one.</div><div><br></div><div>The interface would probably be similar to the current one but just not have the corresponding Initialize/FinalizeFunctionPassManager functions. I think with this method we could also slowly roll out usage of the new PM through the C API and eventually deprecate the legacy PM interface in favor of the new one.</div></div></blockquote><div><br></div><div>+1 for this option.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>3) Add a build flag that switches between PMs used in the C API.</div><div><br></div><div>This could just be some flag in CMake that users can change at build time.</div></div></blockquote><div><br></div><div>I don't think this is a good option because many consumers of the C API don't control the build process of the LLVM they use (e.g., they're linked to a distro-provided library). It's also not useful to programs that want to leave the choice of pass manager to runtime/end users, like clang does with -fexperimental-new-pass-manager.</div><div><br></div><div>Cheers,</div><div>Robin<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Any other suggestions/thoughts?</div><div><br></div><div>- Leo</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>