Please will someone document how clang handles calling conventions

Hello the list,

I am trying to fix a bug in big-endian 64-bit MIPS where clang generates the wrong code for integer arguments spilled to the stack. The target-specific code generates instances of ABIArgInfo, but this seems to be completely undocumented. For example, when I tell it that it should extend these to an i64, it decides to do so as if they'd been stored via memory (i.e. extending the wrong end for big-endian architectures). If I change that behaviour, several tests fail, so presumably it's important for someone, but none of this code has any useful comments.

Please could whoever wrote it (or, at least, someone who understands it), try to provide some documentation? It's bad enough that calling conventions rely on undocumented conventions between the front end and the back end, we don't need to add to that by not even documenting how those conventions are encoded...

David

I’ll go add some comments to CGFunctionInfo.h, but if you paste the C code and LLVM IR that you think it should be lowered to, I can try to come up with the appropriate ABIArgInfos that you need to generate.

One way to think about it is that there is a one-to-one mapping AST-level argument and ABIArgInfo, but a many-to-many mapping from AST-level argument to IR-level argument. A CGFunctionInfo has a list of ABIArgInfos that describe that mapping.

Hi David,

Hello the list,

I am trying to fix a bug in big-endian 64-bit MIPS where clang generates the wrong code for integer arguments spilled to the stack. The target-specific code generates instances of ABIArgInfo, but this seems to be completely undocumented. For example, when I tell it that it should extend these to an i64, it decides to do so as if they'd been stored via memory (i.e. extending the wrong end for big-endian architectures). If I change that behaviour, several tests fail, so presumably it's important for someone, but none of this code has any useful comments.

are you sure you're not falling foul of:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/076456.html

(would only be an issue if there are any bitcasts involved, I think)

cheers
Iain