> > > > I'd also like to propose the inclusion of the recent ABI fixes to the Mips > > > > target but I'm not sure this is a good idea. I'm having difficulty sorting out the > > > > dependencies for these at the moment since they seem to depend on some > > > > of Eric Christopher's Subtarget/TargetMachine refactoring. It may also be a > > > > bit large for a stable release since it's ~50 LLVM patches and ~8 Clang patches > > > > and refactors a large amount of the Mips calling convention code. What do > > > > you think? > > > > > > Can you give me an idea of how important these fixes are? My personal > > > feeling is that big fixes like this can sometimes be OK as long as they > > > are mostly contained to a specific target and that target isn't X86 > > > or ARM. > > > > Without them, the calling convention for big-endian 64-bit Mips targets is very badly broken. Clang is generally consistent with itself, > > but interlinking with GCC-compiled code doesn't work. When I started on this work ~4500 of 5000 tests generated by ABITestGen.py > > produced incorrect output when mixing > GCC and Clang objects. 32-bit and little-endian Mips targets are ok except for a couple rare > > corner cases (e.g. 128-bit float return values). > > It's likely possible to rewrite the patches so that they don't depend on my other work. If you have any questions there or need me to stamp the rewrites as "what should happen if you don't take my patches into account" I'm happy to do so. > > Thanks. > > -ericI believe I've managed to backport them to the release_35 branch but I haven't re-tested them beyond running 'ninja check-all' yet. The patches are currently at https://github.com/dsandersimgtec/clang/commits/release_35, and https://github.com/dsandersimgtec/llvm/commits/release_35_proposed. I'm going to run as much ABI testing as possible on it this evening. _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> From: Daniel Sanders > Sent: 25 November 2014 17:39 > To: Eric Christopher; Tom Stellard > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > Subject: RE: [LLVMdev] Proposed patches for Clang 3.5.1 > > > > > > I'd also like to propose the inclusion of the recent ABI fixes to the Mips > > > > > target but I'm not sure this is a good idea. I'm having difficulty sorting out the > > > > > dependencies for these at the moment since they seem to depend on some > > > > > of Eric Christopher's Subtarget/TargetMachine refactoring. It may also be a > > > > > bit large for a stable release since it's ~50 LLVM patches and ~8 Clang patches > > > > > and refactors a large amount of the Mips calling convention code. What do > > > > > you think? > > > > > > > > Can you give me an idea of how important these fixes are? My personal > > > > feeling is that big fixes like this can sometimes be OK as long as they > > > > are mostly contained to a specific target and that target isn't X86 > > > > or ARM. > > > > > > Without them, the calling convention for big-endian 64-bit Mips targets is very badly broken. Clang is generally consistent with itself, > > > but interlinking with GCC-compiled code doesn't work. When I started on this work ~4500 of 5000 tests generated by ABITestGen.py > > > produced incorrect output when mixing > GCC and Clang objects. 32-bit and little-endian Mips targets are ok except for a couple rare > > > corner cases (e.g. 128-bit float return values). > > > > It's likely possible to rewrite the patches so that they don't depend on my other work. If you have any questions > > there or need me to stamp the rewrites as "what should happen if you don't take my patches into account" I'm > > happy to do so. > > > > Thanks. > > > > -eric > > I believe I've managed to backport them to the release_35 branch but I haven't re-tested them beyond running > 'ninja check-all' yet. The patches are currently at https://github.com/dsandersimgtec/clang/commits/release_35, > and https://github.com/dsandersimgtec/llvm/commits/release_35_proposed. > I'm going to run as much ABI testing as possible on it this evening.I've successfully run the simple vararg test (passing 10 int's in varargs, passing them in a va_list, then printing each one) for all ABI's/endians and mixtures of GCC/Clang. I've also run the first 5,000 ABITestGen.py generated tests for all ABI's/Endians. Big-endian O32 shows a single failure involving small structures (this is not a regression). Big-endian N32 shows about a dozen failures that do not fail on the trunk but aren't regressions either. All other ABI's and Endians are passing successfully. Even with those big-endian N32 failures (which fail without the patches too), this status is a big improvement on the status without the patches so I'm inclined to think we should merge and fix the remaining issues in 3.5.2 (assuming we do one). Tom: Is that ok with you? David: Are you using big-endian N32 or N64? I'm running an event with some students for most of today. I'll check my emails when I can and I'll have my laptop but I probably won't be able to merge anything until after 5pm GMT (9am PST). I'll leave more ABI tests running in the meantime. Apart from the ABI fixes mentioned above, the only patch I'm awaiting approval for is: * r217257 - [mips] Change Feature-related types from unsigned to uint64_t in MipsAsmParser. No functional changes.
On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote:> > From: Daniel Sanders > > Sent: 25 November 2014 17:39 > > To: Eric Christopher; Tom Stellard > > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > > Subject: RE: [LLVMdev] Proposed patches for Clang 3.5.1 > > > > > > > > I'd also like to propose the inclusion of the recent ABI fixes to the Mips > > > > > > target but I'm not sure this is a good idea. I'm having difficulty sorting out the > > > > > > dependencies for these at the moment since they seem to depend on some > > > > > > of Eric Christopher's Subtarget/TargetMachine refactoring. It may also be a > > > > > > bit large for a stable release since it's ~50 LLVM patches and ~8 Clang patches > > > > > > and refactors a large amount of the Mips calling convention code. What do > > > > > > you think? > > > > > > > > > > Can you give me an idea of how important these fixes are? My personal > > > > > feeling is that big fixes like this can sometimes be OK as long as they > > > > > are mostly contained to a specific target and that target isn't X86 > > > > > or ARM. > > > > > > > > Without them, the calling convention for big-endian 64-bit Mips targets is very badly broken. Clang is generally consistent with itself, > > > > but interlinking with GCC-compiled code doesn't work. When I started on this work ~4500 of 5000 tests generated by ABITestGen.py > > > > produced incorrect output when mixing > GCC and Clang objects. 32-bit and little-endian Mips targets are ok except for a couple rare > > > > corner cases (e.g. 128-bit float return values). > > > > > > It's likely possible to rewrite the patches so that they don't depend on my other work. If you have any questions > > > there or need me to stamp the rewrites as "what should happen if you don't take my patches into account" I'm > > > happy to do so. > > > > > > Thanks. > > > > > > -eric > > > > I believe I've managed to backport them to the release_35 branch but I haven't re-tested them beyond running > > 'ninja check-all' yet. The patches are currently at https://github.com/dsandersimgtec/clang/commits/release_35, > > and https://github.com/dsandersimgtec/llvm/commits/release_35_proposed. > > I'm going to run as much ABI testing as possible on it this evening. > > I've successfully run the simple vararg test (passing 10 int's in varargs, passing them in a va_list, then printing each one) for all ABI's/endians and mixtures of GCC/Clang. > > I've also run the first 5,000 ABITestGen.py generated tests for all ABI's/Endians. Big-endian O32 shows a single failure involving small structures (this is not a regression). Big-endian N32 shows about a dozen failures that do not fail on the trunk but aren't regressions either. All other ABI's and Endians are passing successfully. Even with those big-endian N32 failures (which fail without the patches too), this status is a big improvement on the status without the patches so I'm inclined to think we should merge and fix the remaining issues in 3.5.2 (assuming we do one). > Tom: Is that ok with you? > David: Are you using big-endian N32 or N64? > > I'm running an event with some students for most of today. I'll check my emails when I can and I'll have my laptop but I probably won't be able to merge anything until after 5pm GMT (9am PST). I'll leave more ABI tests running in the meantime.I will try to look at the patches today. I'm going to delay the release a week or so, because of all the merge requests I've received, so there is no rush. -Tom> > Apart from the ABI fixes mentioned above, the only patch I'm awaiting approval for is: > * r217257 - [mips] Change Feature-related types from unsigned to uint64_t in MipsAsmParser. No functional changes.
On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote:> > From: Daniel Sanders > > Sent: 25 November 2014 17:39 > > To: Eric Christopher; Tom Stellard > > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > > Subject: RE: [LLVMdev] Proposed patches for Clang 3.5.1 > > > > > > > > I'd also like to propose the inclusion of the recent ABI fixes to the Mips > > > > > > target but I'm not sure this is a good idea. I'm having difficulty sorting out the > > > > > > dependencies for these at the moment since they seem to depend on some > > > > > > of Eric Christopher's Subtarget/TargetMachine refactoring. It may also be a > > > > > > bit large for a stable release since it's ~50 LLVM patches and ~8 Clang patches > > > > > > and refactors a large amount of the Mips calling convention code. What do > > > > > > you think? > > > > > > > > > > Can you give me an idea of how important these fixes are? My personal > > > > > feeling is that big fixes like this can sometimes be OK as long as they > > > > > are mostly contained to a specific target and that target isn't X86 > > > > > or ARM. > > > > > > > > Without them, the calling convention for big-endian 64-bit Mips targets is very badly broken. Clang is generally consistent with itself, > > > > but interlinking with GCC-compiled code doesn't work. When I started on this work ~4500 of 5000 tests generated by ABITestGen.py > > > > produced incorrect output when mixing > GCC and Clang objects. 32-bit and little-endian Mips targets are ok except for a couple rare > > > > corner cases (e.g. 128-bit float return values). > > > > > > It's likely possible to rewrite the patches so that they don't depend on my other work. If you have any questions > > > there or need me to stamp the rewrites as "what should happen if you don't take my patches into account" I'm > > > happy to do so. > > > > > > Thanks. > > > > > > -eric > > > > I believe I've managed to backport them to the release_35 branch but I haven't re-tested them beyond running > > 'ninja check-all' yet. The patches are currently at https://github.com/dsandersimgtec/clang/commits/release_35, > > and https://github.com/dsandersimgtec/llvm/commits/release_35_proposed. > > I'm going to run as much ABI testing as possible on it this evening. > > I've successfully run the simple vararg test (passing 10 int's in varargs, passing them in a va_list, then printing each one) for all ABI's/endians and mixtures of GCC/Clang. > > I've also run the first 5,000 ABITestGen.py generated tests for all ABI's/Endians. Big-endian O32 shows a single failure involving small structures (this is not a regression). Big-endian N32 shows about a dozen failures that do not fail on the trunk but aren't regressions either. All other ABI's and Endians are passing successfully. Even with those big-endian N32 failures (which fail without the patches too), this status is a big improvement on the status without the patches so I'm inclined to think we should merge and fix the remaining issues in 3.5.2 (assuming we do one). > Tom: Is that ok with you? > David: Are you using big-endian N32 or N64? > > I'm running an event with some students for most of today. I'll check my emails when I can and I'll have my laptop but I probably won't be able to merge anything until after 5pm GMT (9am PST). I'll leave more ABI tests running in the meantime. > > Apart from the ABI fixes mentioned above, the only patch I'm awaiting approval for is: > * r217257 - [mips] Change Feature-related types from unsigned to uint64_t in MipsAsmParser. No functional changes.This one is OK, I didn't realize those were private functions, so there shouldn't be an API impact. -Tom