llvm dev - Jun 2017 - Which PM preferred for llvm 4.0 out-of-source passes?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170613/b4abc5bf/attachment.html>

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.

-- 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>

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