[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