[PATCH] D89264: [LICM] Make promotion faster

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 14 12:06:34 PDT 2020


nikic added a comment.

In D89264#2328663 <https://reviews.llvm.org/D89264#2328663>, @asbirlea wrote:

> I tested this in two configurations we use for compiler releases and I'm seeing quite a few runtime regressions in the 10-20% area and a couple of 40% run time regressions.
> It doesn't look worth the compile time gain with such large run time regressions.

Thank you for running those tests! Those results are pretty unexpected to me, as this was not supposed to change the behavior in any substantial way. The two possibilities that come to mind are:

- Those regressions were using the "promotion of promotion" behavior. I originally did not bother supporting this because the situation seemed so contrived, and I would expect EarlyCSE/GVN or anything else doing store-load forwarding to handle it. However, it's also really simple to support and doesn't come with additional compile-time cost, so I extended the patch to handle it (thus also removing the one lit test regression).
- The different processing order for accesses ends up mattering in those cases. Due to AATags intersection the AST is order-dependent, and the different order can result in more or less accesses being promoted (and either direction could be either good or bad for performance).

It's hard to guess without a test case to look at, and unfortunately test-suite doesn't have one. Are any of the regressions you observed in publicly available code that I could check?

I don't really want to give up on this change yet, as the compile-time impact is fairly substantial for some types of code (a few >20% wins on individual files).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89264/new/

https://reviews.llvm.org/D89264



More information about the llvm-commits mailing list