[PATCH] D143898: [CodeGenPrepare] Fold addressing mode into calls
Momchil Velikov via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 14 04:16:50 PST 2023
chill added a comment.
In D143898#4123601 <https://reviews.llvm.org/D143898#4123601>, @efriedma wrote:
> If I'm understanding correctly, the point is that we don't want to block sinking if an address computation has multiple uses, where only some are foldable?
Yes, for when we cannot say we aren't extending live ranges of the address "registers".
> Expressing this in terms of "folding into a call" seems confusing and unnecessary;
To me it looks like a straightforward analogy.
For load/stores we have an addressing computation that's essentially free
when it's a part of the load/store instruction, as opposed to it being a separate instruction and using a simple indirect load/store.
For calls we have an addressing computation that's essentially free
when it's a part of the call sequence, as opposed to it being a separate instruction and using a simple register-to-register move.
> we should just change the logic to allow sinking if we can fold some, but not all, the uses.
> (Maybe including some sort analysis of whether sinking increases the number of times we perform the address computation at runtime.)
IMHO the main issue here is not extending live ranges too much. As for the runtime overhead, sinking a foldable address is assumed to
not increase the execution time, because of the checks in `isLegalAddressingMode` and (with this patch) in `canFoldAddrModeIntoCall`.
Perhaps, with PGO, we could use block frequencies in a way that a non-foldable, infrequently executed user does not prevent sinking, much like
the way we currently use `Attribute::Cold`. However, I don't think that's an alternative to this patch.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D143898/new/
https://reviews.llvm.org/D143898
More information about the llvm-commits
mailing list