llvm dev - Jan 2021 - New pass manager for optimization pipeline status and questions

Keep in mind that LLVM will continue to support the old pass manager via a
cmake option, so if you are a vendor, you can fallback to the old pass
manager and migrate on your own timeline. However, there are costs to
diverging from upstream. As the community migrates to the NPM, the old pass
manager will become less tested over time, and it may accumulate bugs or
performance regressions.

On Mon, Jan 11, 2021 at 3:45 PM Sjoerd Meijer via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Alina & Arthur,
>
> I've investigated the performance impact for us and can now say a
little
> bit more now where we are. Switching now would lead to performance
> regressions (*) in the initial set of 4 benchmarks we care about. One
> benchmark is overall neutral but shows regressions where we don't
really
> want them. Hopefully, your fix for PR48715
> <https://bugs.llvm.org/show_bug.cgi?id=48715> that I raised today
will
> solve that, many thanks for the amazingly speedy reply! A second benchmark
> is a bit of disaster, still need to look into that, and a third shows a
> relatively small regression but it's significant for that benchmark and
am
> looking into that now, and need to look into the fourth benchmark.
>
> Code-generation is *very* different for the cases I am look at and I am
> profiling and analysing things, for which I need some time. This leads to
> my question: can you remind me about the timelines? I hope we can work in
> tandem to have at least the major issues resolved before we switch.
>
> Thanks for working on this, and for your help and speedy replies,
> Sjoerd.
>
> (*) I am mostly looking at smaller cores, and very tight loops (baremetal)
> and guess that most people look at bigger cores where some of these codegen
> differences have no or a different impact.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210112/cbc9b5fa/attachment.html>

To echo the others' replies, the timeline is not fixed but we're looking
at
flipping the default in `opt` as soon as the AMDGPU issues are addressed,
and the CMake option shortly after that - order of within a week.
Variations on the timeline depend on the bugs being filed in the meantime,
hence the importance of testing and bug filing in the next couple of weeks.
The bugs that are not addressed before the switch would still be worked on
after.

As others have said, the cmake option to continue to use the legacy pass
manager will remain in place, and the legacy pass manager code will not be
removed from the tree for months after, while the transition stabilises.
There's also the option to revert the switch once made for major
regressions that may turn up, but the hope is to not get too many last
minute surprises.


On Tue, Jan 12, 2021 at 12:51 PM Reid Kleckner <rnk at google.com> wrote:
> Keep in mind that LLVM will continue to support the old pass manager via a
> cmake option, so if you are a vendor, you can fallback to the old pass
> manager and migrate on your own timeline. However, there are costs to
> diverging from upstream. As the community migrates to the NPM, the old pass
> manager will become less tested over time, and it may accumulate bugs or
> performance regressions.
>
> On Mon, Jan 11, 2021 at 3:45 PM Sjoerd Meijer via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi Alina & Arthur,
>>
>> I've investigated the performance impact for us and can now say a
little
>> bit more now where we are. Switching now would lead to performance
>> regressions (*) in the initial set of 4 benchmarks we care about. One
>> benchmark is overall neutral but shows regressions where we don't
really
>> want them. Hopefully, your fix for PR48715
>> <https://bugs.llvm.org/show_bug.cgi?id=48715> that I raised today
will
>> solve that, many thanks for the amazingly speedy reply! A second
benchmark
>> is a bit of disaster, still need to look into that, and a third shows a
>> relatively small regression but it's significant for that benchmark
and am
>> looking into that now, and need to look into the fourth benchmark.
>>
>> Code-generation is *very* different for the cases I am look at and I am
>> profiling and analysing things, for which I need some time. This leads
to
>> my question: can you remind me about the timelines? I hope we can work
in
>> tandem to have at least the major issues resolved before we switch.
>>
>> Thanks for working on this, and for your help and speedy replies,
>> Sjoerd.
>>
>> (*) I am mostly looking at smaller cores, and very tight loops
>> (baremetal) and guess that most people look at bigger cores where some
of
>> these codegen differences have no or a different impact.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210112/c5cb6386/attachment.html>