[PATCH] D14878: findDeadCallerSavedReg needs to pay attention to calling convention

[Reid Kleckner via llvm-commits]

rnk added a subscriber: rnk.
rnk accepted this revision.
rnk added a reviewer: rnk.
rnk added a comment.
This revision is now accepted and ready to land.

Aside from the magic around '4', this looks great.


================
Comment at: lib/Target/X86/X86FrameLowering.cpp:156
@@ -155,10 +155,3 @@
 
-  static const uint16_t CallerSavedRegs32Bit[] = {
-    X86::EAX, X86::EDX, X86::ECX, 0
-  };
-
-  static const uint16_t CallerSavedRegs64Bit[] = {
-    X86::RAX, X86::RDX, X86::RCX, X86::RSI, X86::RDI,
-    X86::R8,  X86::R9,  X86::R10, X86::R11, 0
-  };
+  const TargetRegisterClass &AvailableRegs = *TRI->getPointerRegClass(*MF, 4);
 
----------------
I'm surprised the magic number 4 isn't an enum. I guess the intention was that it would only be used by tablegen.

Anyway, I think what we should do here is scoop the guts of 'case 4' in `X86RegisterInfo::getPointerRegClass` out into its own method on X86RegisterInfo that we can call directly from here. It should have a name like `getGPRsForTailCall`.

================
Comment at: lib/Target/X86/X86FrameLowering.cpp:160-163
@@ -159,6 +157,1 @@
-
-  static const uint16_t CallerSavedRegs64Bit[] = {
-    X86::RAX, X86::RDX, X86::RCX, X86::RSI, X86::RDI,
-    X86::R8,  X86::R9,  X86::R10, X86::R11, 0
-  };
 
----------------
According to http://www.x86-64.org/documentation/abi.pdf, R10 is used for passing the "static chain pointer". The document doesn't say what that is, but I think it's for GCC's nested functions extension. We have this code in X86CallingConv.td:
  // The 'nest' parameter, if any, is passed in R10.
  CCIfNest<CCIfSubtarget<"isTarget64BitILP32()", CCAssignToReg<[R10D]>>>,
  CCIfNest<CCAssignToReg<[R10]>>,

I think it's impossible to write C/C++ source code that clang will compile into a normal tail call that uses the nest parameter, but I can see why we might want to be cautious and leave out R10. R11 is always a perfectly valid answer, since it's always scratch.


Repository:
  rL LLVM

http://reviews.llvm.org/D14878