[PATCH] D25204: Register Calling Convention, Clang changes

[Erich Keane via cfe-commits]

erichkeane marked 11 inline comments as done.
erichkeane added a comment.

New patch incoming.



> ABataev wrote in ItaniumMangle.cpp:1236-1237
> What if function type is not a FunctionProtoType?

Right, good catch.  I looked at Mangle.cpp which does something very similar, and assumes that FunctionType is a valid cast here, so I've switched this here too, please let me know if that is a wrong assumption.

> rnk wrote in TargetInfo.cpp:3306
> You might want to defend against dynamic C++ records which will have vtable fields.

Hmmm... I'm not sure what behavior would be expected in that case.  Also, I just looked at a bunch of similar 'for' loops for various other reasons, and I don't really see where that is tested elsewhere (so I don't really see how to, besides I.isVirtual?).  In that case, I would suspect that the class is not put into a register?

> rnk wrote in TargetInfo.cpp:3742-3743
> 'classify' takes FreeSSERegs by reference and modifies it, so are you sure this is correct? It means if I have this kind of prototype, we won't pass 'd' in registers because we'll consume four registers for the return value:
> 
>   struct HFA { __m128 f[4]; };
>   HFA __regcall f(HFA a, HFA b, HFA c, HFA d) {
>     ...
>   }

That was my intent, this should allow return values to be in registers as well if I'm reading the spec correctly.  The idea is that register use is 'greedy'.

> rnk wrote in SemaDecl.cpp:8288
> The comment doesn't apply here. Are you sure you don't want some other behavior, like unprototyped functions are actually implicitly void when regcall is used, as in C++?

I suspect you're right.  I am not sure what behavior would be expected, so I think that reverting to the error case is likely the correct "safe" behavior if the spec doesn't say otherwise?

https://reviews.llvm.org/D25204