[LLVMdev] Fwd: [cfe-dev] Handling SRet on Windows x86
rnk at google.com
Thu Mar 28 08:55:10 PDT 2013
On Thu, Mar 28, 2013 at 8:22 AM, Joe Groff <arcata at gmail.com> wrote:
> On Wed, Mar 27, 2013 at 8:15 PM, Chandler Carruth <chandlerc at google.com>wrote:
>> This is why I suggest that the Windows ABI is whatever MSVC happens to
>> do. The mingw ABI happens to consist of a conjunction of what MSVC does for
>> C and what GCC on Linux does for C++. That is a unique and different ABI,
>> and I don't think you can reasonably call it *just* "windows" at any point.
>> This isn't quite true. Mingw and MSVC's ABIs on i386 also differ at the C
> level—for instance, alignment of pass-by-value structs sometimes differs,
> and an sret pointer is callee-cleanup in MSVC but caller-cleanup in Mingw.
> There are other differences too.
Can you clarify what you mean by the "sret pointer is callee-cleanup" vs
What we were specifically hitting yesterday was that MSVC expects the sret
pointer passed into also be returned in eax. LLVM already does this for
x86_64 everywhere. Mingw doesn't do this, but I think it was just a
coincidence. This behavior was undocumented, and that there was probably
no OS API takes a callback which returns a struct larger than 8 bytes.
This makes me think that it would be better if we started returning the
sret pointer from such functions under Mingw for improved compatibility at
the C ABI level. This shouldn't break any mingw code so far as I can tell.
It seems reasonable for a user to expect that the Mingw and Microsoft C
ABIs be compatible, but maybe there are enough other corner cases that this
is just naive.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev