[llvm-dev] Which PM preferred for llvm 4.0 out-of-source passes?

Sean Silva via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 13 11:31:45 PDT 2017

If the legacy PM isn't causing you problems then you don't need to rush and

The new PM is a pretty long term project at this point that is solving
various perceived core issues within LLVM. You'll definitely see a big
announcement when it is time to start porting. The "legacy" PM isn't going
away any time soon. Last I talked with Chandler about it (he is leading the
new PM effort) he was envisioning a 1 or 2 year period once the new PM was
at a point we could finally get rid of the current PM.

Sorry for the confusion. I think everyone at this point realizes that
renaming the current PM to "legacy" was a bit premature (it's been "legacy"
for like 4 years now or something?). You'll see most of the recently
written stuff uses the "new" vs "current" terminology or similar.

-- Sean Silva

On Jun 13, 2017 7:45 AM, "Christian Convey via llvm-dev" <
llvm-dev at lists.llvm.org> wrote:

> I'm maintaining a set of out-of-source passes originally developed for
> llvm 3.6 and 3.7.  They're written to assume that "opt" will use what's now
> called the legacy PM.
> I'm trying to move everything up to llvm 4.0+, and it's not obvious which
> PM these passes should be written for: the legacy PM, or the new one.  Any
> advice?
> One problem is that I can't tell if llvm 4.0's new PM is considered ready
> for prime-time or not.  For example, I see code in the in-source passes and
> in the "opt" program to accommodate *both* the legacy PM and the new one.
> The passes I'm maintaining have the following qualities:
>    - One provides AA
>    - Several of my passes depend on in-source passes: AliasAnalysis,
>    LoopInfoWrapperPass, and MemoryDependencyAnalysis
>    - Some are (conceptually) analysis passes, and some are (conceptually)
>    transform passes.
> If necessary, I *could* convert my passes to be in-source, but that's
> pretty suboptimal for me.
> Thanks,
> Christian
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20170613/867aaaa3/attachment-0001.html>

More information about the llvm-dev mailing list