[llvm-dev] Exposing the New Pass Manager in the LLVM C API

[Robin Kruppe via llvm-dev]

On Fri, 4 Oct 2019 at 03:50, Leonard Chan via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi all,
>
> 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:
>

Hi Leo,

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.

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.

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.


> 1) Just replace the API to expose the new PM instead of the legacy one.
>
> 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.
>
> 2) Add a new interface that exposes the new PM while still keeping the
> current one.
>
> 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.
>

+1 for this option.


>
> 3) Add a build flag that switches between PMs used in the C API.
>
> This could just be some flag in CMake that users can change at build time.
>

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.

Cheers,
Robin


>
> Any other suggestions/thoughts?
>
> - Leo
> _______________________________________________
> 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/20191004/aa5407db/attachment.html>