Hello all,
We would like to contribute a new backend for Qualcomm's Hexagon processor. We will actively maintain the port once it is accepted. Hexagon is a VLIW core that is used principally in modem and low power audio applications in Qualcomm's chip sets.
We have a patch for both llvm and for clang. As this is a new port, these patches are quite large (approximately 26k and 3k lines, respectively). Most of the patches consist of, quite naturally, new files. I have looked for guidelines for submitting a new backend, but have not found anything. Is there anything of that nature? If not, my plan is to simply submit the two patches. Any other suggestions?
Thanks.
Tony Linthicum
There isn't any special prodedure for submitting new backends...
standard patch review guidelines apply. Make sure you include tests.
-Eli
Eli,
When you say "include tests" what exactly do you mean - ability to run
newly produced binary on newly supported target?
Can you please elaborate?
Thanks.
Sergei Larin
Well, it would be nice to know that it can produce working binaries,
but no, you don't need to provide tests like that. Just make sure
there are tests in test/CodeGen/ to check that the backend generates
the expected assembly code for simple cases.
-Eli
Eli,
We can probably think of something like that, but diff on assembly output
is prone to false negatives and depends on the machine independent part of
the compiler...
Maybe someone can suggest more elegant way to verify the basic
functionality?
Thanks.
Sergei Larin
Please look at how all of the existing tests in test/CodeGen/<Target> work
before rejecting the suggestion.
-eric
Maybe tests like test/CodeGen/X86/fast-isel-call.ll, fast-isel-mem.ll, etc.
i.e. very few LLVM IR instructions, each in its own function, and using CHECK:/CHECK-NEXT
Best regards,
--Edwin
Thanks, Eric and Eli. We will do that, and will add some tests to include with our submission.
We are also in the process of getting our simulator and C library (both proprietary) released under a new license so that folks can download them and actually run programs. That's a couple of months away, though, and doesn't really help much for creating LLVM regression tests. Still, it will make reproducing problems easier. 
Tony
It would probably also help to add some systems added to the buildbot
master to test on your actual hardware.
deep
Maybe tests like test/CodeGen/X86/fast-isel-call.ll, fast-isel-mem.ll, etc.
i.e. very few LLVM IR instructions, each in its own function, and using CHECK:/CHECK-NEXT
Another example are msp430 / systemz backends which contain some
"feature" tests.
Thank you. Yes, that's also something we want to do in the relatively near future.
Tony
Hi Tony,
If relevant, I'd suggest splitting it up as:
1. Changes to LLVM code outside your target directory.
2. Your new target directory.
3. Clang patches.
As others have pointed out, you really do need some basic regression tests to make sure that the backend is working. Also, make sure to update this:
http://llvm.org/docs/CodeGenerator.html#targetfeatures
and add a new section to that document on your target.
Thanks!
-Chris
Hi Chris,
Will do! WRT new files, I assume you want them as part of a patch rather than in a tar file or some other format. Is that correct? I will create a basic regression suite for Hexagon modeled from the other back-ends as Eric and others suggested.
Thanks.
Tony
I don't think the specific format is critical for new files. Let me know when you're ready and I can set you up with commit-after-approval access (read llvm/docs/DeveloperPolicy.html and send me the requested info).
-Chris
Sorry if it sounded like I have questioned the need for these tests - rather
I am trying to gather as much info up-front as I can.
Maybe that's why some sort of FAQ for backend submission (as Tony pointed)
is not such a bad idea
Thanks everyone for quick responses. Point is taken.
Sergei Larin