[PATCH] D116424: [PowerPC] add LR to CalleeSavedRegs

Nick Desaulniers via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 5 11:28:37 PST 2022


nickdesaulniers added a comment.

In D116424#3222971 <https://reviews.llvm.org/D116424#3222971>, @efriedma wrote:

> From the test changes, it looks like the current patch completely disables shrink-wrapping in all cases?  Or am I missing something?

Doesn't `@loopInfoRestoreOutsideLoop` in llvm/test/CodeGen/PowerPC/ppc-shrink-wrapping.ll show that that's NOT the case? The `mflr`/`mtlr` pair are sunk+raised respectively since the entry block is conditional and doesn't use the stack.

`@foo` in llvm/test/CodeGen/PowerPC/ppc-shrink-wrapping.ll also has an early return rather than an unconditional prolog. `bgelr` (branch to lr if greater than or equal to). Compared to the codegen with shrink wrap disabled, the `mflr`/`mtlr` pair is unconditional.

Though I'm less convinced about `@@shrinkwrap` in llvm/test/CodeGen/PowerPC/ppc64-rop-protection.ll and `@test` in llvm/test/CodeGen/PowerPC/pr43527.ll.

In D116424#3220197 <https://reviews.llvm.org/D116424#3220197>, @efriedma wrote:

> I would expect that useOrDefCSROrFI should encompass any behavior we care about; in general, there isn't any reason why we can't sink save points past an INLINEASM_BR. It's possible we need to special-case non-allocatable registers in certain cases, or something like that.
> That said, given the current state, the best incremental step might be something like isNonallocatableRegisterCalleeSave.
> I mean, adding a new target hook named something like isNonallocatableRegisterCalleeSave

Perhaps that's another approach I can try, but I suspect it will have the same results on tests. Let me see.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116424



More information about the llvm-commits mailing list