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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hal Finkel via llvm-dev
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hal Finkel via llvm-dev
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" <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hal Finkel 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" <
> [hidden email]> 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
> > [hidden email]
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Loading...