[LLVMdev] backend documentation

[Paul Sokolovsky]

Hello,

On Sun, 24 Feb 2013 07:25:03 -0800
Reed Kotler <rkotler at mips.com> wrote:


> > InstrInfo.td for my backend now. After reading "Writing an LLVM
> > backend" and "Creating an LLVM Backend for the Cpu0 Architecture",
> > many black holes have remained. These tutorials describe it on

"Cpu0" links to Tricore port thesis (google for "tricore llvm"), and I
found it to be more insightful than Cpu0 doc itself (which needs more
work IMHO). It shows usage of custom addressing mode, predicates, and
some issues at least that version of LLVm had (with ability to annotate
and propagate annotations thru instruction selection graph, I wonder how
latest LLVM in that regard).

> It's very simple because nobody is working on the Sparc port to make
> it a commercial compiler for the Sparc platform; yet at the same time
> it has complex patterns, custom inserters etc and all the elements of
> a more serious port.
> 
> Most people learn LLVM by trying to do something with it and not just 
> reading about it. I too wanted some better documentation and more 
> complete examples and such but if you wait for that; you will wait
> for a very long time (several years at least).
> 
> Tablegen is a vital tool to LLVM; yet there is little written about
> it; especially not about the code generation use of it.

With my LLVM brainstorming, I find it soothing idea to think of
tablegen as another separate layer. Because treating it as an
unalienable part of LLVM, it's really hard to see how this all differs
from GCC, except that they were missing to PR their GIMPLE IR for long
time.

I'm sure Tablegen is a good expressive language, and sure that if
someone is to write generic solution, they would come up with something
similar to Tablegen eventually. I just wonder if that's exactly the
case when (re)implementing own adhoc solution offers much milder
learning curve...

Anyway, it would be nice to have a backend for (abstract) trivial CPU
with just accumulator, index register and stack pointer and devoid
of any tablegen usage (or maybe it would be tolerable for such CPU,
after all, most of tablegen hardness comes from lack of keyword
arguments and MLAs a typical machine def is ridden with). Such backend
could be used to easily bootstrap a new arch backend, next might be to
use any extra regs as just stack frame cache, and then it will be
just good time to learn advanced tablegen stuff.

[]

-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com