[PATCH] D145211: Relax cross-section branches

[Daniel Hoekwater via Phabricator via llvm-commits]

dhoekwater added a comment.

In D145211#4540838 <https://reviews.llvm.org/D145211#4540838>, @efriedma wrote:

> Alternatively, we could try to make register allocation understand that branches clobber x16, I guess?  Haven't thought through how exactly that would work.  The advantages of letting the linker split: one, we can completely avoid the extra instructions in libraries that are small, and two, linker-generated thunks would move the thunking code outside the hot section.  But I won't insist on it (we can always revise this part later).

I have a follow-up patch to this one that defers relaxation to the linker when possible and picks the manual relaxation strategy that minimally impacts the hot section. 
Making register allocation understand x16 clobbering would be a neat idea; I'd definitely like to explore it when fine-tuning MFS. Thanks for the review!



================
Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.cpp:287
+      .addReg(Reg)
+      .addReg(AArch64::SP)
+      .addImm(-16);
----------------
efriedma wrote:
> dhoekwater wrote:
> > efriedma wrote:
> > > Do we know at this point that the function isn't using the red zone?  (We usually use the emergency spill slot for this sort of situation.)
> > Because BranchRelaxation runs after Frame Finalization, we can't add an emergency spill slot at this point.
> > 
> > We could add a spill slot to every function just in case spilling is necessary, but I would expect it to degrade performance.
> > 
> > Since Red Zone on AArch64 isn't widely used, it should be alright if it isn't compatible with MFS/BBSections on AArch64. I'll add an explicit check here to assert that we're not doing anything we shouldn't.
> Can we write some reasonable heuristic for whether we might need to spill?  I mean, during frame finalization, we should at least be able to tell if there's any cold code in the function.
> 
> If disabling red zone usage in the relevant functions is the simplest way forward, I guess I'm fine with that.
> Can we write some reasonable heuristic for whether we might need to spill?
Since frame finalization happens before `MachineFunctionSplitter`/`BBSections` run, there isn't any way to tell what blocks may be hot or cold at this point.

We could hypothetically say "officially, MFS / bbsections are unsupported with Red zone, but they do work 99% of the time" and minimize pushing the stack pointer, but that sounds hairy.

AFAICT, disabling red zone doesn't affect those that use MFS / bbsections. The AArch64 ABI Procedure Call Standard specifies that not writing past the stack pointer is a [universal constraint](https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#6451universal-stack-constraints) and doesn't mention the red zone at all (although [Apple](https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Respect-the-stacks-red-zone) and [Windows](https://github.com/MicrosoftDocs/cpp-docs/blob/main/docs/build/arm64-windows-abi-conventions.md#red-zone) platforms still respect it).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145211