[PATCH] D22045: [X86] Support of no_caller_saved_registers attribute (Clang part)

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.

================
Comment at: include/clang/Basic/Attr.td:1674
@@ +1673,3 @@
+                                   TargetSpecificAttr<TargetAnyX86> {
+  let Spellings = [GNU<"no_caller_saved_registers">];
+  let Subjects = SubjectList<[FunctionLike], WarnDiag, "ExpectedFunction">;
----------------
Yes, though interrupt should be handled in a separate patch since it's a logically separate change.

================
Comment at: include/clang/Basic/AttrDocs.td:2205
@@ +2204,3 @@
+Use this attribute to indicate that the specified function has no
+caller-saved registers.  That is, all registers are callee-saved.
+The compiler generates proper function entry and exit sequences to
----------------
> Please, correct me if I am mistaken, but calling convention determine not only what the callee and the caller function saved registers are, but also how we move parameters to the called function, right?

Correct.

> The idea behind no_caller_saved_registers attribute, is that it can be combined with any other calling convention, and it only override the callee/caller saved register list, but not the way parameters are passed to the called function.
>
> So, using a calling convention for this attribute will not be right.

Okay, that makes sense to me, but we should document how this interacts with calling convention attributes more clearly. Specifically, we should call out that this does not affect the calling convention and give an example of what gets generated for a function that combines a caller-saved calling convention with this attribute.

================
Comment at: include/clang/CodeGen/CGFunctionInfo.h:479
@@ +478,3 @@
+  /// Whether this function saved caller registers.
+  unsigned NoCallerSavedRegs : 1;
+
----------------
This is unfortunate as it will bump the bit-field length to 33 bits, which seems rather wasteful. Are there any bits we can steal to bring this back down to a 32-bit bit-field?


https://reviews.llvm.org/D22045