[llvm-commits] Patch: new backend for Hexagon processor

Eli Friedman eli.friedman at gmail.com
Mon Nov 14 12:54:36 PST 2011


On Mon, Nov 14, 2011 at 11:56 AM, Tony Linthicum <tlinth at codeaurora.org> wrote:
> Hi folks,
>
> I have attached two patches that implement a new backend for Qualcomm's VLIW
> processor, Hexagon. As was suggested, I've broken the contribution up into 3
> patches: one for llvm changes, one containing new files from
> lib/Target/Hexgon, and one for clang (contained in another e-mail to
> cfe-commits).
>
> I had previously tested the patches with both test-suite and test (including
> a few new Hexagon specific tests) and it passed cleanly.  I pulled again on
> Friday and picked up the new build changes and while I have added Hexagon to
> this mechanism and successfully built, there seems to be a problem with
> generating Hexagon code now.  I will be working on correcting this problem,
> but in the mean time I wanted to go ahead and send these patches to begin
> the review process.
>
> I've sent these compressed with bzip2.  If that is inconvenient for anyone
> wishing to review the patches, please let me know and I'll send them to you
> in another format.
>
> These patches are, obviously, not my work alone.  In addition to myself,
> other members of my team will likely be responding to any questions that
> come up.
>
> Thanks!

Just took a look over the LLVM changes outside your target.

You have a *lot* of builtins, but there isn't really much to say about
that, beyond "do all these builtins represent something which can't be
represented in IR otherwise?".

--- a/include/llvm/InitializePasses.h
+++ b/include/llvm/InitializePasses.h
@@ -233,6 +233,7 @@ void initializeVerifierPass(PassRegistry&);
 void initializeVirtRegMapPass(PassRegistry&);
 void initializeInstSimplifierPass(PassRegistry&);

+void initializeHexagonHardwareLoopsPass(PassRegistry&);
 }

 #endif

This change shouldn't be necessary; only target-independent passes
need to be listed here, IIRC.

Your changes to add Data128bitsDirective etc. seem a bit confused...
".uleb128" is not a 128-bit integer in the sense you're using it.
Also, please separate out the MC changes into a separate patch;
they're interesting changes mixed into a bunch of mechanical changes,
and it would be nice to have more eyes on them.

-Eli




More information about the llvm-commits mailing list