[LLVMdev] guidance on backend writing; canonical example?

James Courtier-Dutton james.dutton at gmail.com
Wed Mar 13 06:41:25 PDT 2013

On 13 March 2013 01:50, Jason E. Aten <j.e.aten at gmail.com> wrote:
>> Chris Lattner, Mon Nov 15 12:06:18 CST 2010, wrote:
>> If anyone was really interested in this, I'd strongly suggest a complete
>> rewrite of the C backend: make use the existing target independent code
>> generator code (for legalization etc) and
>> then just put out a weird ".s file" at the end. -Chris
> I see that Chris made the above suggestion a while ago.  Are there other
> suggestions for how to re-architect the C backend? I'm thinking of helping
> with Roel Jordan's effort to revive the C backend, but I don't know the best
> way to implement backends. Is there a prototype to follow?

I think the biggest challenge with a C backend is making it useful to
the audience.
With most other backends, they don't have to be human readable, so the
layout does not need to be pretty, it only needs to create efficient
code for a target CPU, that always has a restricted register space.
The C backend would be a very different animal. Unlimited register
space. The LLVM IR optimizations needed would be ones that make the
resulting C source code more readable, in effect, the opposite or
reverse of a majority of the current LLVM IR optimizations.
There is also the convertion from CFG (as used in LLVM IR) to AST (as
used in clang) in order to output C.
Conversion from CFG to AST is difficult, I think it would be useful to
have a whole new infrastucture to let the user easily refactor the AST
to make it look more readable when the final C is generated. The
reason for using AST, it to aid in reducing the amount of "goto"s and
instead provide structure.
Are there any other existing backends that have an unlimited register
space or do AST?

More information about the llvm-dev mailing list