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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
