[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