[PATCH] D113967: [RISCV] Reverse the order of loading/storing callee-saved registers.

Hsiangkai Wang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 17 04:35:48 PST 2021


HsiangKai added a comment.

In D113967#3135737 <https://reviews.llvm.org/D113967#3135737>, @jrtc27 wrote:

> Though, I'm unconvinced about whether the hazard in the epilogue matters in practice. In a simple in-order micoarchitecture if restoring ra stalls then it doesn't matter where that is, you can't execute out-of-order. In a superscalar core you'll just speculate past the ret anyway, which should predict accurately for anything with a half-decent RAS, though I guess you'll have unresolved speculation for longer that might be an issue. Is there a particular microarchitecture you've measured an appreciable difference for this on?

What if there are two bubbles between load instruction and the using instruction in the pipeline? In the current RISC-V LLVM implementation, there is only one instruction, i.e., stack pointer adjustment, between `load ra` and `ret`. The `ret` will cost an additional cycle for the bubble unless we schedule the epilogue to fill the bubble. However, there is no scheduling for epilogue code in LLVM. In GCC implementation, it will put the `load ra` at first in the epilogue code. Here is an example. https://godbolt.org/z/3rnfrcnhT

I agree we could keep the order of prologue in the current implementation. I reorder them just for symmetry. It is not necessary in this patch. The point is to reorder the epilogue restoring code.

The intention of this patch is to have more instructions to fill the bubbles if there are any bubbles between load and use. It will increase the live range of ra, but it should have no negative impact in the epilogue code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113967



More information about the llvm-commits mailing list