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

Amjad Aboud via cfe-commits cfe-commits at lists.llvm.org
Sun Jul 24 04:46:57 PDT 2016


aaboud marked an inline comment as done.

================
Comment at: include/clang/Basic/Attr.td:1657
@@ +1656,3 @@
+                                   TargetSpecificAttr<TargetAnyX86> {
+  let Spellings = [GNU<"no_caller_saved_registers">];
+  let Subjects = SubjectList<[FunctionLike], WarnDiag, "ExpectedFunction">;
----------------
aaron.ballman wrote:
> Any particular reason this isn't (also) a C++-style attribute under the clang namespace?
I am not sure about that, I was just following the way the "interrupt" attribute was defined.
Do you think we should change both to consider C++ style attribute as well?

================
Comment at: include/clang/Basic/AttrDocs.td:2177
@@ +2176,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
----------------
aaron.ballman wrote:
> How does this interact with calling convention attributes? For instance, if I have a function that is explicitly marked cdecl and has this attribute, what is the behavior for EAX, ECX, and EDX?
> 
> Also, why is this an attribute rather than a calling convention? I'm wondering how this works through function pointers, for instance (whether it is intended to work or not).
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?

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.

H.J., can you confirm this?


https://reviews.llvm.org/D22045





More information about the cfe-commits mailing list