[LLVMdev] Proposed patches for Clang 3.5.1

[Daniel Sanders]

> -----Original Message-----
> From: Tom Stellard [mailto:tom at stellard.net]
> Sent: 26 November 2014 15:50
> To: Daniel Sanders
> Cc: Eric Christopher; Dr D. Chisnall; LLVM Developers Mailing List
> (llvmdev at cs.uiuc.edu)
> Subject: Re: [LLVMdev] Proposed patches for Clang 3.5.1
> 
> 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.

That's a relief :-). I'll see if I can fix the N32 issues that remain on this branch.

So far, I've run the first 90,000 tests for each ABI/endian with only the failures explained above.

> -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.
> 
> This one is OK, I didn't realize those were private functions, so there
> shouldn't be an API impact.

Thanks. Merged in r222875.