llvm dev - Apr 2009 - [LLVMdev] Porting LLVM backend is no fun yet

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^)

G

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090411/71df421b/attachment.html>

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^)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090413/663b9755/attachment.html>

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

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.
Your observations are accurate; LLVM's CodeGen is comparatively
less mature in this area. There are numerous examples of these
symptoms.

There certainly are wishlist items for TableGen and TableGen-based
instruction descriptions, though I don't know of an official list.   
Offhand,
a few things that come to mind are the ability to handle nodes with
multiple results, something analogous to GCC's multi-alternative
constraints, the ability to generate more of the Legalize tables
automatically, and the ability to generate more of the TargetInstrInfo
hooks automatically.  There's no plan for things like this at the
moment though; they will get done only when someone steps up
and implements them.
>
> 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.
I guess this is just a matter of familiarity, and perhaps of choosing
an advantageous font.

Dan

Hello, Alex
> 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.
That's true. TableGen can automate many important cases, but surely
not the everything, since targets differs *alot*. Extending TableGen
language to handle all possible cases would yield another language and
it's quite questionable whether it will be better than C++ :)
> 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.
Recently on the horizont appeared some group of enthusiasts willing to
write MSP430 backend. I'm trying to make their learning curve less
steep and thus started such backend by myself. You can monitor the git
repository at http://repo.or.cz/w/llvm/msp430.git. It contains dummy
backend and also has several early steps already done.

There is also some description what's going on
http://community.livejournal.com/ru_llvm/, but unfortunately, only in
russian. Hopefully someday it become a proper "Backend for Dummies"
article.

Hope this will help somehow.
-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

Dan Gohman wrote:
> There certainly are wishlist items for TableGen and TableGen-based
> instruction descriptions, though I don't know of an official list.
> Offhand,
> a few things that come to mind are the ability to handle nodes with
> multiple results, 
Is there an official workaround, BTW?

- Volodya

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? :-)

Evan
>
> 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^)
>
> G
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090413/ad5b9ecb/attachment.html>

Dan Gohman wrote:
> There certainly are wishlist items for TableGen and TableGen-based
> instruction descriptions, though I don't know of an official list.   
> Offhand, a few things that come to mind are the ability to handle nodes
with
> multiple results, something analogous to GCC's multi-alternative
> constraints, the ability to generate more of the Legalize tables
> automatically, and the ability to generate more of the TargetInstrInfo
> hooks automatically.  There's no plan for things like this at the
> moment though; they will get done only when someone steps up
> and implements them.
>   
Hi Dan,

Please pass along any other whishlist items you find.  I'll dig through 
the llvmdev archives and see what I can find.  I'm willing to lend a 
hand and make some design proposals as things become more clear for me.  
One thing I could use is nested multiclasses--the ability to call defm 
within a multiclass.

G

Evan Cheng wrote:
>
> 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? :-)
Hi Evan,

Forgive me for focusing so much on complaints and omitting praise.  I 
enthusiastically applaud LLVM in every other respect!  LLVM is the 
coolest, grooviest swiss-army-knife of compiler technology I have had 
the pleasure of working with.  I'm certain that my own deficient C++ 
skills contributes to my frustrations, and is hardly the fault of LLVM.  
The thrust of my message is that I want to learn better what TableGen 
can already do, and contribute to making it a more flexible and complete 
target description tool.  One reason I had an easier time with the 
CGEN+GCC port was because there were already several good quality ports 
to targets that were very similar (m32r was one).  LLVM just isn't as 
old and broadly ported as CGEN+GCC, so I'm not benefiting as much from 
others' work.  Now I get to be something of a pioneer and will 
doubtlessly acquire some arrows in my back to prove it. 8^)

G

On Monday 13 April 2009 12:44, Dan Gohman wrote:
> There certainly are wishlist items for TableGen and TableGen-based
> instruction descriptions, though I don't know of an official list.
Here's a few on my list in addition to what you mentioned:

1. Multiclass inheritance.  I've implemented that here and am working toward
   getting it upstream.

2. defm can inherit from multiple multiclasses.  Also implemented here and 
   working its way upstream.

3. Passing subclasses as arguments so one can re-use template code.  
   This is really, really hard to implement the way things are right now.  I 
   tried and gave up.  :(

4. !nameconcat - works like !strconcat but looks up a symbol when it's done.
   This is really useful when trying to reuse dag patterns.  Also implemented 
   here and working its way upstream.

5. !cast - Given a string, look up a symbol, expecting a particular type for 
   that symbol.

6. Documentation!  I hope to contribute something here as I can.  I've leard
A
   LOT over the last few weeks.

                                                      -Dave