[cfe-dev] [LLVMdev] [RFC] TileGX, a new backend for Tilera's many core processor

Reed Kotler rkotler at mips.com
Wed Mar 13 05:07:39 PDT 2013


On 03/08/2013 03:26 PM, Joerg Sonnenberger wrote:
> On Fri, Mar 08, 2013 at 11:13:04AM -0800, Bill Wendling wrote:
>> The LLVM community prefers small, self-contained patches. Please split
>> up your patches into small chunks that can be easily reviewed. Keep in
>> mind that the compiler needs to work after each pass goes in. :-)
>
> Just like with AArch64, this is not a reasonable requirement for a new
> backend. The tarball contains essentially three different parts:
> (1) Generic changes to recogniz TileGX as triple etc.
> (2) The target subdirectory.
> (3) The clang logic for va_arg etc.
>
> While (1) can be and should be split off, it doesn't change match in
> terms of patch size, since the majority will stay in item (2).
>
> Joerg
>
It's possible to split up the patch. I think it took me 40 patches to 
push the mips16 port into LLVM.

That's the choice you have with LLVM. If you don't push small patches 
then you'll be stuck with having to split up a big patch.

Nobody wants to try and review a whole port and figure out what each 
piece does and which test cases apply to which parts of the port.

Later on , for example, if a test case fails, people can figure out 
which part of the code relates to that test case.

People will spend time reviewing your patches and the bottom line is 
that onces the code is in there, it's hard to get it out or to get 
people to change or clean up things. That's easier to do when they first
push upstream.

I did not wait till the very end but was faced several times with 
splitting up large and complex patches.

Now that I'm more comfortable with LLVM I push patches almost daily.

I too found it easier while initially doing the port to not be pushing
changes. Now I do things differently and even with a new port would push 
it in small changes.


Reed





More information about the cfe-commits mailing list