[cfe-dev] Custom calling conventions in C code

Matthijs Kooijman matthijs at stdin.nl
Thu Jul 10 01:54:47 PDT 2008


Hi Chris,

>> [Specifiying custom calling conventions from C]

> There isn't currently a way to do this, you'd have to use specific named 
> conventions like "cdecl" "stdcall" "pascal" etc, along with attributes.
The problem is that I'd like to have a completely custom and backend-specific
calling convention, and using one of those keywords would be abuse.

> I think it would be a great thing for compiler hackers to have a mechanism 
> to access an arbitrary calling convention, but I also think it would be a 
> disaster to expose this to end user code.  The problem is that not all 
> constructs are valid with every calling convention, and if there is ever a 
> large install base of code using "calling convention 19" in their C code, 
> we'd have to support that forever.  CC#'s are supposed to be an internal 
> implementation detail of the IR.
In our case, we are working with a specific C variant, which is mostly C
compatible and can therefore be parsed by clang completely. So, I'm looking
for a way to be able to write down a custom calling convention from within
that language, without having to modify clang locally. So, support for a
__attribute__(()) extension would be just fine.

I see something like this in a similar way as the annotate attribute. It's
possible to write it down, but clang won't guarantee anything about how it's
handled. In other words, its only useful when you know beforehand which
backend is going to be handling your code. Support a specific calling
convention is then something for the backend, which might or might not
continue support for a specific calling convention. Doesn't that sound
reasonable?

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080710/10e4b939/attachment.sig>


More information about the cfe-dev mailing list