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 caller-cleanup? 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... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/c17d0712/attachment.html>
On Thu, Mar 28, 2013 at 8:55 AM, Reid Kleckner <rnk at google.com> wrote:> 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 > caller-cleanup? >In the epilog for a function with an indirect struct return argument, MSVC emits a 'ret 4' to pop the return pointer argument. Mingw emits a 'ret'.> 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. >Good catch. Returning the sret pointer in eax shouldn't affect Mingw compatibility since EAX isn't preserved across calls in either the Microsoft or Mingw ABIs (IIRC). -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/bc16f597/attachment.html>
On Thu, Mar 28, 2013 at 8:59 AM, Joe Groff <arcata at gmail.com> wrote:> On Thu, Mar 28, 2013 at 8:55 AM, Reid Kleckner <rnk at google.com> wrote: > >> 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 >> caller-cleanup? >> > > In the epilog for a function with an indirect struct return argument, MSVC > emits a 'ret 4' to pop the return pointer argument. Mingw emits a 'ret'. > > >> 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. >> > > Good catch. Returning the sret pointer in eax shouldn't affect Mingw > compatibility since EAX isn't preserved across calls in either the > Microsoft or Mingw ABIs (IIRC). >Yeah, but the ret / ret 4 discrepancy means they're still fundamentally incompatible, so this wouldn't help. =/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/9acf558f/attachment.html>