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

[Tobias Grosser via llvm-dev]

On Tue, Jun 13, 2017, at 08:31 PM, Sean Silva via llvm-dev wrote:
> If the legacy PM isn't causing you problems then you don't need to rush
> and
> switch.
> 
> 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.

Right. The new pass manages has been made great progress and is indeed
more and more stable. Most of the core passes are ported to the new pass
manager and even in Polly we started to add support for it. Still, if
you don't need any of its features (or are not aware of why you would
need something different) it is likely easier to just stay with the
"legacy" pass manager for now. Porting passes is in fact pretty easy.
Chandler did a very good job here.

Best,
Tobias


> 
> -- 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
> >
> >
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev