[llvm-dev] Exposing the New Pass Manager in the LLVM C API
Nicolai Hähnle-Montoro via llvm-dev
llvm-dev at lists.llvm.org
Tue Oct 8 05:31:47 PDT 2019
On Fri, Oct 4, 2019 at 3:50 AM Leonard Chan via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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:
+1 to allowing the NewPM to be used from the C API.
The stability expectations on the C interface are higher than those on
the C++ interface. You should treat the C API as stable as much as
possible. This means your option (2) -- adding a new parallel API for
the NewPM, while keeping the old PM API -- is really the only _real_
option that is available here.
Cheers,
Nicolai
>
> 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.
>
> 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.
>
> 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
--
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
More information about the llvm-dev
mailing list