[LLVMdev] Porting LLVM backend is no fun yet
echeng at apple.com
Mon Apr 13 11:30:32 PDT 2009
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.
Surely these are two separate issues. TableGen being less than capable
then CGEN doesn't have anything to do with the overall quality of rest
of LLVM. Yes it's true it could be harder to port LLVM to certain
architectures. But it's probably not the case for every target. Can
you do a good port of x86 using CGEN? :-)
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev