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

Sean Silva via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 10 16:18:37 PDT 2015


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
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150910/35be98b6/attachment.html>


More information about the llvm-commits mailing list