[LLVMdev] Porting LLVM backend is no fun yet
wuerges at gmail.com
Mon Apr 13 10:19:48 PDT 2009
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
> 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
LAPS - Laboratorio de Automacao de Projeto de Sistemas
UFSC - Universidade Federal de Santa Catarina
More information about the llvm-dev