[LLVMdev] Porting LLVM backend is no fun yet

[Emílio Wuerges]

By the way. I'm searching for more detailed documentation about
instruction itineraries in LLVM, used by the schedulers.
Can someone point me over that?

On Mon, Apr 13, 2009 at 2:01 PM, Alex Karahalios <alex at karahalios.org> wrote:
> Hi Greg,
> I understand your frustration. I've been on this mailing list for
> a little over a year hoping that by osmosis I could get a a better handle on
> writing a back end for LLVM. Although I feel more comfortable with the
> nomenclature, I still do not have a clue as to how to begin (actually I do,
> but it sounds more dramatic saying it this way). I've read the
> documentation, but TableGen seems to just be a glorified front end
> for generating C++ records. I was hoping for something that would allow me
> to specify my target machine (more inline with what GCC does) and then just
> stand back and watch the target code be generated. I guess a deeper
> understanding of Target classes is mandatory before proceeding to use
> TableGen.
> I guess what would help would be a tutorial that shows how one goes about
> writing a back-end for a fictitious target machine - something similar to
> "Porting GCC for Dunces"
> (http://ftp.axis.se/pub/users/hp/pgccfd/pgccfd.pdf). Also
> a pre-made "Dummy" back-end that had some basic instructions would also go a
> long way in helping someone write a back-end.
> Alex Karahalios
> On Apr 11, 2009, at 5:03 PM, Greg McGary wrote:
>
> As we've already seen, David Chisnall prefers hacking LLVM over GCC (see
> http://www.informit.com/articles/article.aspx?p=1215438): "In contrast,
> every time I look at the GCC code, it takes two people to
> prevent me from clawing my eyeballs out."
>
> I'm sorry to report that so-far I have had the opposite experience.  Some
> years ago, I ported binutils (via CGEN) and GCC to an embedded RISC CPU and
> found it the process straightforward and pleasant.  CGEN was especially
> handy for describing a sometimes quirky RISC instruction set and offered
> great flexibility for factoring-out commonalities.  By contrast, I have
> found TableGen to be much more rigid and brittle.  There are too many
> constructs that need to be special-cased, and the existing ports do them in
> gratuitously different ways.  There also seem to be too many layers of
> classes and helper functions in proportion to what's being specified.  I
> guess that sums-up my gripe: low signal/noise and gratuitous complexity.
> Sorry to be complaining rather than proposing solutions.  When I better get
> the hang of all of this, I expect to have some ideas on how to improve
> TableGen.  Is there a development plan or wishlist for TableGen?  I see
> nothing on the wiki yet.
>
> I must also say that the LLVM code is considerably "denser" because of the
> unfortunate choice of BiCapitalizedIdentifierNames.  Underscores lend some
> horizontal whitespace to names and make their subtokens visually distict.
> BiCapped code is kinda like German with its cumbersome compound nouns.
>
> Enough complaining for now--back to banging skull on stone!  8^)
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



-- 
Emilio Wuerges
LAPS - Laboratorio de Automacao de Projeto de Sistemas
UFSC - Universidade Federal de Santa Catarina
Brasil