Christian Convey via llvm-dev
2017-Jun-13 14:44 UTC
[llvm-dev] 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>
Sean Silva via llvm-dev
2017-Jun-13 18:31 UTC
[llvm-dev] Which PM preferred for llvm 4.0 out-of-source passes?
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>
Tobias Grosser via llvm-dev
2017-Jun-13 22:16 UTC
[llvm-dev] Which PM preferred for llvm 4.0 out-of-source passes?
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