[llvm] [SCEV] Collect and merge loop guards through PHI nodes with multiple incoming values (PR #113915)

Florian Hahn via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 8 06:30:08 PST 2024


fhahn wrote:

> > Haven't looked at the implementation yet, but this change has some compile-time impact: https://llvm-compile-time-tracker.com/compare.php?from=a256e89fd1b9f42d3f29df42d4f21ea823476ff3&to=24ca499a1d02f88bee077c2a3135dfae8f1094fe&stat=instructions:u
> 
> Thanks for checking! I've limited the recursion depth to 1 as Florian suggested; that should hopefully help with compile times.

This already cut down compile-time quite a bit for most configs but there are still some cases where it increases in the 0.06-0.11% range: https://llvm-compile-time-tracker.com/compare.php?from=724b432410fd59c63cc313d41824eda5ec84052f&to=a1c2970d6d6715bdf0c903ee7507c24a58310011&stat=instructions:u

There's also some reductions for some workloads, plus a number of code changes. @juliannagele do you know if they are all due to vectorizers or something else?  In order to bring down compile-time even more it might be good to further limit the # of predecessors we check in the recursive case.


 One surprising thing is that there's a notable change in compile-time in `stage1-O0-g`, but nothing in the O0 pipeline should use the loop guards AFAIK. @nikic do you have any idea what could be the cause for the changes there?

https://github.com/llvm/llvm-project/pull/113915


More information about the llvm-commits mailing list