[llvm-dev] optnone/skipping passes in the new pass manager

[Johannes Doerfert via llvm-dev]

On 6/8/20 6:29 PM, Arthur Eubanks via llvm-dev wrote:
> Hmm it looks like getting NPM to work with opt is non-trivial. Only a small
> portion of the opt functionality works with NPM :(

I am very much looking forward to use the NPM by default but this sounds 
like a problem we need to fix first :(.

You happen to have some "list" of things that are missing?



> On Mon, Jun 8, 2020 at 3:36 PM Robinson, Paul <paul.robinson at sony.com>
> wrote:
>
>> Maybe you could change the default PM in opt and see what fails?
>>
>> --paulr
>>
>>
>>
>> *From:* Arthur Eubanks <aeubanks at google.com>
>> *Sent:* Monday, June 8, 2020 5:52 PM
>> *To:* Robinson, Paul <paul.robinson at sony.com>
>> *Cc:* Chandler Carruth <chandlerc at gmail.com>; llvm-dev at lists.llvm.org
>> *Subject:* Re: [llvm-dev] optnone/skipping passes in the new pass manager
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jun 8, 2020 at 7:11 AM Robinson, Paul <paul.robinson at sony.com>
>> wrote:
>>
>> When the optnone design was being discussed, Chandler specifically
>> rejected having the pass manager involved in the decision (which was the
>> original proposed design).  Assuming he still feels the same way now, if
>> the existing `skipFunction` calls aren’t being executed under the new pass
>> manager, then each pass that has that call will need to be modified
>> accordingly (added to the NPM path or moved to some common point).  It
>> would be best if the `skipFunction` calls were handled consistently in all
>> passes so that it would become part of the normal pass boilerplate.
>>
>> Makes sense, thanks for the background. I'll see if there's a clean way to
>> make this functionality easy to use in the NPM.
>>
>>
>>
>> I suspect any `skipFunction` or opt-bisection tests have been written to
>> force the old pass manager, which is why defaulting to the new pass manager
>> doesn’t fail anywhere.
>>
>> I took a closer look at some optnone tests and they use opt instead of
>> clang. opt still defaults to the legacy pass manager regardless of clang's
>> default.
>>
>> --paulr
>>
>>
>>
>> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Arthur
>> Eubanks via llvm-dev
>> *Sent:* Sunday, June 7, 2020 7:59 PM
>> *To:* llvm-dev <llvm-dev at lists.llvm.org>
>> *Subject:* [llvm-dev] optnone/skipping passes in the new pass manager
>>
>>
>>
>> Looking through some of the remaining test failures under the new pass
>> manager, I've narrowed down one of the failures in GWPAsan(!) to the fact
>> that the new pass manager doesn't properly skip passes like the old pass
>> manager. For example, when a function is marked optnone, or when using
>> https://llvm.org/docs/OptBisect.html
>> <https://urldefense.com/v3/__https:/llvm.org/docs/OptBisect.html__;!!JmoZiZGBv3RvKRSx!t3zrtZFFWm0ifdWgL9SiWSNETodW3pMSJ8m8YWqK139cicFp_U1juO0D90-VinpUWg$>
>> .
>>
>>
>>
>> Lots of passes (e.g. SROA) will do the following under the legacy pass
>> manager:
>>
>>
>>
>>    bool runOnFunction(Function &F) override {
>>      if (skipFunction(F))
>>        return false;
>>
>>      // do pass
>>
>>    }
>>
>>
>>
>> What's the right way to proceed with this? There are 50-100 calls to
>> skipFunction() in legacy passes. This doesn't even account for other types
>> of IR units, like skipModule(Module&).
>>
>>
>>
>> I suppose it's possible to manually go in and add in the same check in the
>> new passes, but that seems tedious (and how do you test that at scale?
>> clearly there aren't many tests for it right now since check-llvm passes
>> under the new pass manager). An alternative of skipping passes at the pass
>> manager level would require marking each pass as necessary/optional (I
>> think...).
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20200608/103b5d5e/attachment.html>