[LLVMdev] Proposed patches for Clang 3.5.1

[Tom Stellard]

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