[PATCH] D12773: [PM] Port SROA to the new pass manager.

Thu Sep 10 17:30:37 PDT 2015

I think '-load' is going to have to work *fundamentally* differently with
the new pass manager, but I'm confident it will work there.

The idea is that when you load a pass as a plugin, you get a callback that
allows you to add your own passes to the pass manager. The pass manager is
already doing full type erasure so it can have passes in it which it has
never seen before.

I was planning on building any plugin support at the very end, because it
isn't an important use case to me. It'd be great if people that are
actually using this could contribute it, as otherwise I'm much more likely
to focus on essentially all the other use cases until it comes time to try
to rip *out* the old pass manager.

On Thu, Sep 10, 2015 at 4:50 PM Pete Cooper <peter_cooper at apple.com> wrote:

> Hey Chandler
>
> Its a shame to expose the internal details of passes in the header, but
> the only alternative I can think of is an extra layer of indirection to an
> Impl, and I don’t think thats really any better.  So in terms of that I
> can’t offer any help.
>
> However, one thing I would like to make sure is that whatever solution we
> agree on here will work for ‘-load’ passes.  We certainly don’t want to
> refactor a huge number of passes then have to do it all again because of
> that constraint.  Are you confident that the SROA change here would work if
> SROA is loaded dynamically?  Perhaps its worth fixing the LLVMHello.dylib
> pass before proceeding to any other passes after SROA.
>
> Cheers,
> Pete
>
> On Sep 10, 2015, at 4:18 PM, Sean Silva via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>
>
> On Thu, Sep 10, 2015 at 4:13 PM, Chandler Carruth <chandlerc at gmail.com>
> wrote:
>
>> On Thu, Sep 10, 2015 at 3:26 PM Sean Silva <chisophugis at gmail.com> wrote:
>>
>>> In `[LLVMdev] Heads up: Pass Manager changes will be starting shortly`
>>> one of the goals was "I'm going to build a bridge so that an existing Pass
>>> can be inserted into the new pass manager with some adaptors and everything
>>> will just work".
>>>
>>> My reading of this is that there would be an incremental step where we
>>> have fully transitioned to using the new pass manager, but existing passes
>>> are using wrappers. We would then incrementally move each pass to
>>> "natively" use the new pass manager as needed (e.g. for the inliner). So
>>> I'm surprised that we are porting SROA so early.
>>>
>>> Did I miss/forget something? I've noticed that in last fall's devmtg
>>> talk it looked like you have "port the existing pass pipeline" as a
>>> blocking item, so I assume there was some sort of realization in the
>>> interim. Could you elaborate on this (or point to a thread I missed?).
>>>
>>
>> I'm not sure which thread, but there was an update at one point where I
>> essentially explained that I could find no clear way to have a packaged
>> bridge that Just Worked. The cleanest solution I have found is to be able
>> to share all the business logic, while having essentially two entry points,
>> and to make the entry points as small and share as much code as possible.
>> The wrappers for the legacy pass manager try to do this, but the pattern
>> for doing it is exactly what I wanted feedback on here.
>>
>
> Okay, makes sense.
>
> -- Sean Silva
>
>
>>
>>
>>>
>>> -- Sean Silva
>>>
>>> On Thu, Sep 10, 2015 at 2:02 PM, Chandler Carruth via llvm-commits <
>>> llvm-commits at lists.llvm.org> wrote:
>>>
>>>> chandlerc created this revision.
>>>> chandlerc added reviewers: dexonsmith, bogner.
>>>> chandlerc added a subscriber: llvm-commits.
>>>>
>>>> In some ways this is a very boring port to the new pass manager as there
>>>> are no interesting analyses or dependencies or other oddities.
>>>>
>>>> However, this does introduce the first good example of a transformation
>>>> pass with non-trivial state porting to the new pass manager. I've tried
>>>> to carve out patterns here to replicate elsewhere, and would appreciate
>>>> comments on whether folks like these patterns:
>>>>
>>>> - A common need in the new pass manager is to effectively lift the pass
>>>>   class and some of its state into a public header file. Prior to this,
>>>>   LLVM used anonymous namespaces to provide "module private" types and
>>>>   utilities, but that doesn't scale to cases where a public header file
>>>>   is needed and the new pass manager will exacerbate that. The pattern
>>>>   I've adopted here is to use the namespace-cased-name of the core pass
>>>>   (what would be a module if we had them) as a module-private namespace.
>>>>   Then utility and other code can be declared and defined in this
>>>>   namespace. At some point in the future, we could even have
>>>>   (conditionally compiled) code that used modules features when
>>>>   available to do the same basic thing.
>>>>
>>>> - I've split the actual pass run method in two in order to expose
>>>>   a private method usable by the old pass manager to wrap the new class
>>>>   with a minimum of duplicated code. I actually looked at a bunch of
>>>>   ways to automate or generate these, but they are all quite terrible
>>>>   IMO. The fundamental need is to extract the set of analyses which need
>>>>   to cross this interface boundary, and that will end up being too
>>>>   unpredictable to effectively encapsulate IMO. This is also
>>>>   a relatively small amount of boiler plate that will live a relatively
>>>>   short time, so I'm not too worried about the fact that it is boiler
>>>>   plate.
>>>>
>>>> The rest of the patch is totally boring but results in a massive diff
>>>> (sorry). It just moves code around and removes or adds qualifiers to
>>>> reflect the new name and nesting structure.
>>>>
>>>> http://reviews.llvm.org/D12773
>>>>
>>>> Files:
>>>>   include/llvm/InitializePasses.h
>>>>   include/llvm/Transforms/Scalar/SROA.h
>>>>   lib/LTO/LTOCodeGenerator.cpp
>>>>   lib/Transforms/Scalar/SROA.cpp
>>>>   lib/Transforms/Scalar/Scalar.cpp
>>>>
>>>>
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>>
>>>>
>>>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150911/e957519d/attachment.html>