[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
> 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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev