Kuperstein, Michael M
2014-Dec-15 14:43 UTC
[LLVMdev] ABI incompatability when passing vector parameters on 32-bit x86
Hi all, Recently, Reid Kleckner found an ABI incompatibility between clang and GCC in the way vector parameters are passed on 32-bit x86. (This is documented in PR21510.) Specifically, GCC uses XMM0-XMM2 to pass the first 3 __m128 parameters, and the rest are passed on the stack. Clang passes an additional parameter by register, using XMM0-XMM3. The same applies to __m256 with YMM0-2 vs. YMM0-3. In theory, it would apply to __m512 as well, but currently clang doesn't support passing __m512 in x86 mode at all. ICC has the same behavior as GCC, and it seems that MSVC in 32-bit mode only *allows* up to 3 vector parameters per function (when not using __vectorcall), and these 3 are passed in XMM0-XMM2, which is closer to the GCC behavior. Unfortunately, it seems like there is no ABI specification to support either behavior as "correct": while the x32 ("ILP32") ABI explicitly specifies XMM0-XMM2, the latest version of the i386 psABI is too old to contain any useful information. Still, XMM0-XMM2 looks like the common choice, and I think the current clang behavior should be considered a bug. The problem is that, regardless of whether it's a bug or not, this behavior has been in place for many years, and changing it would mean breaking ABI compatibility with older clang versions. On the other hand, not changing it would mean continued ABI incompatibility with GCC. (This only applies to _m128 and _m256. Making the _m512 behavior GCC-compatible should be painless). Reid (and I hope I'm not misrepresenting him here) suggested leaving the behavior as-is on platforms where clang is the system compiler (Darwin and BSD) and changing it elsewhere. However, I'm afraid interpreting the calling convention differently (compatible / incompatible with GCC) on different platforms may be confusing to end-uses. Any thoughts on this, especially from OS/libraries people, will be very appreciated. Thanks, Michael --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141215/7e83fb4e/attachment.html>
Kuperstein, Michael M
2014-Dec-23 06:37 UTC
[LLVMdev] ABI incompatability when passing vector parameters on 32-bit x86
Ping? Given that nobody objected so far, I'm considering changing it for all platforms, but I'd really like to get some feedback before I make an ABI-breaking change. ;-) Michael From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kuperstein, Michael M Sent: Monday, December 15, 2014 16:43 To: LLVMdev at cs.uiuc.edu Subject: [LLVMdev] ABI incompatability when passing vector parameters on 32-bit x86 Hi all, Recently, Reid Kleckner found an ABI incompatibility between clang and GCC in the way vector parameters are passed on 32-bit x86. (This is documented in PR21510.) Specifically, GCC uses XMM0-XMM2 to pass the first 3 __m128 parameters, and the rest are passed on the stack. Clang passes an additional parameter by register, using XMM0-XMM3. The same applies to __m256 with YMM0-2 vs. YMM0-3. In theory, it would apply to __m512 as well, but currently clang doesn't support passing __m512 in x86 mode at all. ICC has the same behavior as GCC, and it seems that MSVC in 32-bit mode only *allows* up to 3 vector parameters per function (when not using __vectorcall), and these 3 are passed in XMM0-XMM2, which is closer to the GCC behavior. Unfortunately, it seems like there is no ABI specification to support either behavior as "correct": while the x32 ("ILP32") ABI explicitly specifies XMM0-XMM2, the latest version of the i386 psABI is too old to contain any useful information. Still, XMM0-XMM2 looks like the common choice, and I think the current clang behavior should be considered a bug. The problem is that, regardless of whether it's a bug or not, this behavior has been in place for many years, and changing it would mean breaking ABI compatibility with older clang versions. On the other hand, not changing it would mean continued ABI incompatibility with GCC. (This only applies to _m128 and _m256. Making the _m512 behavior GCC-compatible should be painless). Reid (and I hope I'm not misrepresenting him here) suggested leaving the behavior as-is on platforms where clang is the system compiler (Darwin and BSD) and changing it elsewhere. However, I'm afraid interpreting the calling convention differently (compatible / incompatible with GCC) on different platforms may be confusing to end-uses. Any thoughts on this, especially from OS/libraries people, will be very appreciated. Thanks, Michael --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141223/ec4c0c06/attachment.html>
Bob Wilson
2014-Dec-23 17:01 UTC
[LLVMdev] ABI incompatability when passing vector parameters on 32-bit x86
I agree with Reid and do not think we should change the ABI for Darwin.> On Dec 22, 2014, at 10:37 PM, Kuperstein, Michael M <michael.m.kuperstein at intel.com> wrote: > > Ping? > > Given that nobody objected so far, I’m considering changing it for all platforms, but I’d really like to get some feedback before I make an ABI-breaking change. ;-) > <> > Michael > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kuperstein, Michael M > Sent: Monday, December 15, 2014 16:43 > To: LLVMdev at cs.uiuc.edu > Subject: [LLVMdev] ABI incompatability when passing vector parameters on 32-bit x86 > > Hi all, > > Recently, Reid Kleckner found an ABI incompatibility between clang and GCC in the way vector parameters are passed on 32-bit x86. > (This is documented in PR21510.) > > Specifically, GCC uses XMM0-XMM2 to pass the first 3 __m128 parameters, and the rest are passed on the stack. Clang passes an additional parameter by register, using XMM0-XMM3. The same applies to __m256 with YMM0-2 vs. YMM0-3. In theory, it would apply to __m512 as well, but currently clang doesn’t support passing __m512 in x86 mode at all. ICC has the same behavior as GCC, and it seems that MSVC in 32-bit mode only *allows* up to 3 vector parameters per function (when not using __vectorcall), and these 3 are passed in XMM0-XMM2, which is closer to the GCC behavior. > > Unfortunately, it seems like there is no ABI specification to support either behavior as “correct”: while the x32 (“ILP32”) ABI explicitly specifies XMM0-XMM2, the latest version of the i386 psABI is too old to contain any useful information. > Still, XMM0-XMM2 looks like the common choice, and I think the current clang behavior should be considered a bug. > > The problem is that, regardless of whether it’s a bug or not, this behavior has been in place for many years, and changing it would mean breaking ABI compatibility with older clang versions. > On the other hand, not changing it would mean continued ABI incompatibility with GCC. > (This only applies to _m128 and _m256. Making the _m512 behavior GCC-compatible should be painless). > > Reid (and I hope I’m not misrepresenting him here) suggested leaving the behavior as-is on platforms where clang is the system compiler (Darwin and BSD) and changing it elsewhere. However, I’m afraid interpreting the calling convention differently (compatible / incompatible with GCC) on different platforms may be confusing to end-uses. > > Any thoughts on this, especially from OS/libraries people, will be very appreciated. > > Thanks, > Michael > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141223/7f57806b/attachment.html>
Maybe Matching Threads
- RFC: Adding Support For Vectorcall Calling Convention
- [PATCH] x86: AVX instruction emulation fixes
- [LLVMdev] Unexpected spilling of vector register during lane extraction on some x86_64 targets
- [LLVMdev] RFB: Would like to flip the vector shuffle legality flag
- [LLVMdev] RFB: Would like to flip the vector shuffle legality flag