<div dir="ltr">FWIW MSVC has a similar flag called /homeparams:<div><a href="https://msdn.microsoft.com/en-us/library/6exwh0y6.aspx">https://msdn.microsoft.com/en-us/library/6exwh0y6.aspx</a><br></div><div><br></div><div>So, I think there is some value in this feature, even ignoring vector and floating point arguments, which won't fit into these general-purpose register parameters. Win64 doesn't have this problem because they don't pass values larger than 8 bytes by value, including vectors. On Win64, we should also store arguments into the 32 byte shadow space allocated by the caller for varargs purposes to match tools expecting MSVC's behavior.</div><div><br></div><div>Your patch doesn't appear to update the dwarf or seh call frame info, which is very important. I might grab this at some point, since I have some experience with that.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 26, 2017 at 9:13 PM, David Gwynne via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ola,<br>
<br>
ive been looking at adding support for an -msave-args option for<br>
use on x86_64. the short explanation of it is that it makes x86_64<br>
function prologues store their register arguments on the stack. the<br>
purpose of this is to make the arguments trivially accessible for<br>
things like stack traces with arguments.<br>
<br>
as per<br>
<a href="https://blogs.oracle.com/sherrym/entry/obtaining_function_arguments_on_amd64" rel="noreferrer" target="_blank">https://blogs.oracle.com/<wbr>sherrym/entry/obtaining_<wbr>function_arguments_on_amd64</a>,<br>
this was originally implemented by sun in the various compilers<br>
they use to support the debugging facilities in their system. ive<br>
been looking at doing the same thing on openbsd for the same reasons<br>
which you can see at<br>
<a href="http://marc.info/?l=openbsd-tech&m=149308081923303&w=2" rel="noreferrer" target="_blank">http://marc.info/?l=openbsd-<wbr>tech&m=149308081923303&w=2</a> and<br>
<a href="http://marc.info/?l=openbsd-tech&m=149325930004885&w=2" rel="noreferrer" target="_blank">http://marc.info/?l=openbsd-<wbr>tech&m=149325930004885&w=2</a>.<br>
<br>
there's a strong possibility that openbsd will switch to clang and<br>
llvm on amd64, so i had a look at implementing this in clang. i<br>
know the illumos community is interested in this functionality,<br>
presumably as a way forward from the old gcc theyre still using.<br>
<br>
i am a fair way along but i wanted to ask for advice on how to<br>
proceed from this point. ive only been hacking on llvm for a day<br>
or so, so id appreciate some advice from people with experience<br>
before i head too far down what could be the wrong path.<br>
<br>
its not obvious to me what what the etiquette is for sending diffs<br>
so it's inline below. it is also available at<br>
<a href="https://mild.embarrassm.net/~dlg/diff/llvm.msave.trunk" rel="noreferrer" target="_blank">https://mild.embarrassm.net/~<wbr>dlg/diff/llvm.msave.trunk</a><br>
<br>
this does enough that it generally works. it basically shoves some<br>
extra PUSHes into the prologue, and tries to account for them<br>
properly so other uses of the frame and the epilogue works.<br>
<br>
so there are some issues with the code:<br>
<br>
- it (probably) doesnt handle functions that return structs<br>
- it doesnt realign the stack pointer after consuming space on it<br>
- it doesnt restrict the use of -msave-args to generation of 64bit<br>
code.<br>
<br>
so my questions are:<br>
<br>
1. my understanding is if a function returns a struct, the caller<br>
is responsible for allocating space for the struct and passes a<br>
pointer to the callee via RDI, which takes a register away from<br>
arguments.<br>
<br>
is that true? what's the best way to detect that in<br>
X86FrameLowering::<wbr>emitPrologue()?<br>
<br>
2. i copied get64BitArgumentGPRs from X86ISelLowering.cpp.<br>
<br>
i need this so i know which registers to push onto the stack and<br>
in which order.<br>
<br>
should i move it to X86RegisterInfo.cpp? could someone give me a<br>
pointer on following the FIXME, ie, how could i get that stuff from<br>
tblgen?<br>
<br>
if anyone has some tips for me, it would be greatly appreciated.<br>
<br>
thanks in advance,<br>
dlg<br>
<br>
Index: lib/Target/X86/X86.td<br>
==============================<wbr>==============================<wbr>=======<br>
--- lib/Target/X86/X86.td (revision 301500)<br>
+++ lib/Target/X86/X86.td (working copy)<br>
@@ -235,6 +235,9 @@<br>
"LEA instruction with certain arguments is slow">;<br>
def FeatureSlowIncDec : SubtargetFeature<"slow-incdec"<wbr>, "SlowIncDec", "true",<br>
"INC and DEC instructions are slower than ADD and SUB">;<br>
+def FeatureSaveArgs<br>
+ : SubtargetFeature<"save-args", "SaveArgs", "true",<br>
+ "Save register arguments on the stack.">;<br>
def FeatureSoftFloat<br>
: SubtargetFeature<"soft-float", "UseSoftFloat", "true",<br>
"Use software floating point features.">;<br>
Index: lib/Target/X86/<wbr>X86FrameLowering.cpp<br>
==============================<wbr>==============================<wbr>=======<br>
--- lib/Target/X86/<wbr>X86FrameLowering.cpp (revision 301500)<br>
+++ lib/Target/X86/<wbr>X86FrameLowering.cpp (working copy)<br>
@@ -47,6 +47,7 @@<br>
// standard x86_64 and NaCl use 64-bit frame/stack pointers, x32 - 32-bit.<br>
Uses64BitFramePtr = STI.isTarget64BitLP64() || STI.isTargetNaCl64();<br>
StackPtr = TRI->getStackRegister();<br>
+ SaveArgs = STI.getSaveArgs();<br>
}<br>
<br>
bool X86FrameLowering::<wbr>hasReservedCallFrame(const MachineFunction &MF) const {<br>
@@ -83,7 +84,7 @@<br>
/// or if frame pointer elimination is disabled.<br>
bool X86FrameLowering::hasFP(const MachineFunction &MF) const {<br>
const MachineFrameInfo &MFI = MF.getFrameInfo();<br>
- return (MF.getTarget().Options.<wbr>DisableFramePointerElim(MF) ||<br>
+ return (MF.getTarget().Options.<wbr>DisableFramePointerElim(MF) || SaveArgs ||<br>
TRI->needsStackRealignment(MF) ||<br>
MFI.hasVarSizedObjects() ||<br>
MFI.isFrameAddressTaken() || MFI.hasOpaqueSPAdjustment() ||<br>
@@ -850,6 +851,25 @@<br>
MI->getOperand(3).setIsDead();<br>
}<br>
<br>
+// FIXME: Get this from tablegen.<br>
+static ArrayRef<MCPhysReg> get64BitArgumentGPRs(<wbr>CallingConv::ID CallConv,<br>
+ const X86Subtarget &Subtarget) {<br>
+ assert(Subtarget.is64Bit());<br>
+<br>
+ if (Subtarget.isCallingConvWin64(<wbr>CallConv)) {<br>
+ static const MCPhysReg GPR64ArgRegsWin64[] = {<br>
+ X86::RCX, X86::RDX, X86::R8, X86::R9<br>
+ };<br>
+ return makeArrayRef(std::begin(<wbr>GPR64ArgRegsWin64), std::end(GPR64ArgRegsWin64));<br>
+ }<br>
+<br>
+ static const MCPhysReg GPR64ArgRegs64Bit[] = {<br>
+ X86::RDI, X86::RSI, X86::RDX, X86::RCX, X86::R8, X86::R9<br>
+ };<br>
+ return makeArrayRef(std::begin(<wbr>GPR64ArgRegs64Bit), std::end(GPR64ArgRegs64Bit));<br>
+}<br>
+<br>
+<br>
/// emitPrologue - Push callee-saved registers onto the stack, which<br>
/// automatically adjust the stack pointer. Adjust the stack pointer to allocate<br>
/// space for local variables. Also emit labels used by the exception handler to<br>
@@ -1123,6 +1143,36 @@<br>
BuildCFI(MBB, MBBI, DL, MCCFIInstruction::<wbr>createDefCfaRegister(<br>
nullptr, DwarfFramePtr));<br>
}<br>
+<br>
+ if (SaveArgs) {<br>
+ ArrayRef<MCPhysReg> GPRs =<br>
+ get64BitArgumentGPRs(Fn-><wbr>getCallingConv(), STI);<br>
+ unsigned arg_size = Fn->arg_size();<br>
+ unsigned RI = 0;<br>
+ int64_t SaveSize = 0;<br>
+<br>
+ for (MCPhysReg Reg : GPRs) {<br>
+ if (++RI > arg_size)<br>
+ break;<br>
+<br>
+ SaveSize += SlotSize;<br>
+<br>
+#if 1<br>
+ BuildMI(MBB, MBBI, DL, TII.get(X86::PUSH64r))<br>
+ .addReg(Reg)<br>
+ .setMIFlag(MachineInstr::<wbr>FrameSetup);<br>
+#else<br>
+ // MOV64mr Reg, -SaveSize(%rbp)<br>
+ addRegOffset(BuildMI(MBB, MBBI, DL, TII.get(X86::MOV64mr)),<br>
+ FramePtr, true, -SaveSize)<br>
+ .addReg(Reg)<br>
+ .setMIFlag(MachineInstr::<wbr>FrameSetup);<br>
+#endif<br>
+ }<br>
+<br>
+ StackSize += SaveSize;<br>
+ MFI.setStackSize(StackSize);<br>
+ }<br>
}<br>
<br>
// Mark the FramePtr as live-in in every block. Don't do this again for<br>
Index: lib/Target/X86/<wbr>X86FrameLowering.h<br>
==============================<wbr>==============================<wbr>=======<br>
--- lib/Target/X86/<wbr>X86FrameLowering.h (revision 301500)<br>
+++ lib/Target/X86/<wbr>X86FrameLowering.h (working copy)<br>
@@ -36,6 +36,8 @@<br>
<br>
unsigned SlotSize;<br>
<br>
+ bool SaveArgs;<br>
+<br>
/// Is64Bit implies that x86_64 instructions are available.<br>
bool Is64Bit;<br>
<br>
Index: lib/Target/X86/X86Subtarget.<wbr>cpp<br>
==============================<wbr>==============================<wbr>=======<br>
--- lib/Target/X86/X86Subtarget.<wbr>cpp (revision 301500)<br>
+++ lib/Target/X86/X86Subtarget.<wbr>cpp (working copy)<br>
@@ -312,6 +312,7 @@<br>
SlowLEA = false;<br>
SlowIncDec = false;<br>
stackAlignment = 4;<br>
+ SaveArgs = false;<br>
// FIXME: this is a known good value for Yonah. How about others?<br>
MaxInlineSizeThreshold = 128;<br>
UseSoftFloat = false;<br>
Index: lib/Target/X86/X86Subtarget.h<br>
==============================<wbr>==============================<wbr>=======<br>
--- lib/Target/X86/X86Subtarget.h (revision 301500)<br>
+++ lib/Target/X86/X86Subtarget.h (working copy)<br>
@@ -293,6 +293,9 @@<br>
/// entry to the function and which must be maintained by every function.<br>
unsigned stackAlignment;<br>
<br>
+ /// Whether function prologues should save register arguments on the stack.<br>
+ bool SaveArgs;<br>
+<br>
/// Max. memset / memcpy size that is turned into rep/movs, rep/stos ops.<br>
///<br>
unsigned MaxInlineSizeThreshold;<br>
@@ -356,6 +359,8 @@<br>
return &getInstrInfo()-><wbr>getRegisterInfo();<br>
}<br>
<br>
+ bool getSaveArgs() const { return SaveArgs; }<br>
+<br>
/// Returns the minimum alignment known to hold of the<br>
/// stack frame on entry to the function and which must be maintained by every<br>
/// function for this subtarget.<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div>