[PATCH] D115497: [Inline] Disable deferred inlining

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 13 10:23:31 PST 2022


nikic added a comment.

In D115497#3241114 <https://reviews.llvm.org/D115497#3241114>, @jonpa wrote:

> This seems to cause a huge regression on SystemZ/imagick. If I use "-mllvm -inline-deferral" with trunk, I see a 25% improvement!
>
> There is a slight regression on xalanc with deferred inlining, but otherwise this doesn't really seem to hurt much on this architecture.
>
> My question then is if we should re-enable it on SystemZ, or if you would recommend some alternative that perhaps could give us performance back on imagick while having a sounder algorithm?

This doesn't really seem like something that should be controlled by target options. It's hard to discuss alternatives without knowing more details about the issue affecting imagick -- there //are// some variations on the "deferred inlining" concept we could implement, but I don't know what would help imagick in particular. Changes to inlining heuristics tend to be very hit and miss.

I believe the main inlining-related peculiarity of the SystemZ target is that it increases all inlining thresholds by a factor of three (https://github.com/llvm/llvm-project/blob/c0671e2c9b5c70fbcda277dcd5321d052ca2a2ee/llvm/lib/Target/SystemZ/SystemZTargetTransformInfo.h#L39). No other non-GPU target does this, and I imagine that it can make inlining behavior on SystemZ very different from other targets. It might be worthwhile to double check whether that threshold multiplier is really needed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115497



More information about the llvm-commits mailing list