[llvm-dev] Enabling Loop Distribution Pass as default in the pipeline of new pass manager
Florian Hahn via llvm-dev
llvm-dev at lists.llvm.org
Wed Jul 14 05:18:32 PDT 2021
> On 25 Jun 2021, at 12:23, Sanne Wouda <Sanne.Wouda at arm.com> wrote:
>
> Hi,
> Do you have any data on how often LoopDistribute triggers on a larger set of programs (like llvm-test-suite + SPEC)? AFAIK the implementation is very limited at the moment (geared towards catching the case in hmmer) and I suspect lack of generality is one of the reasons why it is not enabled by default yet.
> It would be good to have some fresh numbers on how often LoopDistribute triggers. From what I remember, there are a handful of cases in the test suite, but nothing that significantly affects performance (other than hmmer, obviously).
> Also, there’s been an effort to improve the cost-modeling for LoopDistribute (https://reviews.llvm.org/D100381 <https://reviews.llvm.org/D100381>) Should we make progress in that direction first, before enabling by default?
> Unfortunately, there were some problems with this effort. First, the current implementation of LoopDistribute relies heavily on LoopAccessAnalysis, which made it difficult to adapt.
>
> More importantly though, I'm not convinced that LoopDistribute will be beneficial other than in cases where it enables more vectorization. (The memcpy detection gcc might be interesting, I didn't look at that.) It reduces both ILP and MLP, which in some cases might be made up by lower register or cache pressure, but this is hard or impossible for the compiler to know.
>
I think we should be able to make an educated guess at least if we wanted to, although it won’t be straightforward. I think there can be cases where loop distribution can be beneficial on its own, especially for large loops where enough parallelism remains after distributing, but they can be highly target-specific.
> While working on this, with a more aggressive LoopDistribute across several benchmarks, I did not see any improvements that didn't turn out to be noise, and plenty of cases where it was actively degrading performance.
>
Thanks for the update! It might be good to close the loop on the review as well?
Cheers,
Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210714/84df2e78/attachment.html>
More information about the llvm-dev
mailing list