can i avoid saving CSRs for functions with noreturn

hi, list,

i am making a llvm compiler for shader-like programs. as we known, shader programs are short and have less function calls. i found that i have to save/restore callee-saved register(CSR) in prolog and epilog. because I can violate ABI from driver(c code) and shader, i plan to append the attribute ‘noreturn’ to all shader functions.

in PrologEpilogInserter.cpp, you can find that it actually honor an attribute ‘naked’ which avoid saving CSR. however, it also skips generating stack-pointer adjustment, which i need. my patch is as follows. i am targeting RISC processor. can anyone tell me this patch is generic ?

diff --git a/lib/CodeGen/PrologEpilogInserter.cpp b/lib/CodeGen/PrologEpilogInserter.cpp
index c791ffb…f19b47a 100644
— a/lib/CodeGen/PrologEpilogInserter.cpp
+++ b/lib/CodeGen/PrologEpilogInserter.cpp
@@ -96,7 +96,7 @@ bool PEI::runOnMachineFunction(MachineFunction &Fn) {

// Add the code to save and restore the callee saved registers

  • if (!F->hasFnAttr(Attribute::Naked))
  • if (!F->hasFnAttr(Attribute::Naked) && !F->hasFnAttr(Attribute::NoReturn))

// Allow the target machine to make final modifications to the function



can anyone tell me this patch is generic ?

It looks like which registers would have been saved is calculated
elsewhere, and it looks suspiciously like the targets use that
information for other purposes (debug/exception info, possibly
calculating object offsets from sp, perhaps even storing registers for
other purposes).

If it was me, I'd implement this feature by preventing the
callee-saved registers from getting on that list in the first place.
Though even that's a risky change and would need some careful testing
across many targets.

The whole area of prologue and epilogue emission is one of the most
complicated and fragile parts of compiler backends in my experience.




(Adding the list back in).

i know where to calculate CSRs. the additional stack space is calculated in
PEI::calculateCalleeSavedRegisters. the real instructions are inserted in
my point is why llvm code honor 'naked' but does not 'noreturn' for CSR.

And to me it sounds like a good point, but it should probably be done
carefully so that LLVM's internal data structures remain consistent
with reality. It looks like other parts of the backends rely on the
values produced by calculateCalleeSavedRegisters being accurate.