[llvm-dev] Status of new pass manager work

[Sean Silva via llvm-dev]

On Thu, May 5, 2016 at 1:52 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:

> On Thu, May 5, 2016 at 1:50 PM Sean Silva <chisophugis at gmail.com> wrote:
>
>> On Thu, May 5, 2016 at 1:24 PM, Chandler Carruth <chandlerc at gmail.com>
>> wrote:
>>
>>> On Thu, May 5, 2016 at 12:12 PM Sean Silva <chisophugis at gmail.com>
>>> wrote:
>>>
>>>> On Thu, May 5, 2016 at 1:29 AM, Chandler Carruth via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> Greetings folks,
>>>>>
>>>>> I just wanted to post a brief update on the status of the new pass
>>>>> manager. Philip asked me to do this at last month's social and Life
>>>>> intervened, but he's still got a great point, so I wanted to get it out
>>>>> there with one day to spare before he nagged me again. =D
>>>>>
>>>>> I'll keep it very brief and high level. If folks have questions about
>>>>> anything, happy to dig into it.
>>>>>
>>>>> - The core framework is there. It works, and we even have CGSCC passes
>>>>> using both Module and Function analyses with caching and everything. Yay!
>>>>> We also have initial loop pass infrastructure thanks to Justin! Yay!
>>>>>
>>>>> - The biggest missing piece of infrastructure IMO is communicating
>>>>> invalidation information between two parts of the pass manager itself when
>>>>> they are operating over the results of an analysis. Both the loop passes
>>>>> and the CGSCC passes really need this. I'm currently working on this and
>>>>> hope to finish the first cut at CGSCC stuff for this in a few days.
>>>>>
>>>>> - The second biggest missing piece is a good system for managing sets
>>>>> of related analyses for the purpose of invalidation. Justin and I have
>>>>> discussed using designated enums that form sets, but there hasn't been a
>>>>> lot of concrete progress here.
>>>>>
>>>>
>>>> Can we maybe just have a function for each "set"? e.g. you just call
>>>> `preserveAllCFGPasses(PA)`.
>>>> We can maybe stamp out `preserveAllCFGPasses` and any others from the
>>>> .def file to make sure there is a single point of truth.
>>>>
>>>
>>> My preference would be to keep the participation in a set local to the
>>> analysis implementation.
>>>
>>
>> Do you envision a generic set mechanism or just a couple hardcoded sets?
>>
>
> Honestly haven't spent enough time looking at it to be terribly specific.
> This was just some ideas tossed around with Justin I'm afraid.
>
> If this is an area you want to work on, try some things out and propose it?
>


I may try my hand at getting a simple `preserveAllCFGAnalyses(PA)` in place
so that we at least can represent that semantic where it is needed instead
of leaving FIXME comments.

I'll leave it to you and Justin to come up with the right design, since you
guys have it all in your heads; I'm fairly clueless about this stuff.
Whatever you guys ultimately settle on you should be able to migrate to it
with a simple NFC search and replace of the `preserveAllCFGAnalyses(PA)`
calls.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/3841a5e1/attachment.html>