Rotluchs

We have an IRC channel (#firm on FreeNode), a mailing list (see libfirm.org) and there are github mirrors for cparser (https://github.com/MatzeB/cparser) and libfirm (https://github.com/MatzeB/libfirm/). If you want to report a bug, there's our bugtracker (also linked on libfirm.org)

Fixed, thanks for the report. (: (stupid gcc extensions sigh)

libFirm is not tied to compiling C. It is a more general intermediate representation library, which provides an API to attach a frontend, e.g. there is one for X10, too. Further, I doubt that we have enough good C compilers.

1. How exceptions are to be implemented is dictated by the runtime environment. Support for exceptions in general is currently work in progress.

2. libFirm's register alloctor does not make any restrictions about the calling convention. If you want to have a call, which passes the first and seventh parameter in %esi and %edx, then you can specify that in the intermediate representation and the register allocator will handle that. Of course there is no generic mechanism to export this insanity to the frontend, but the backend itself can generate code for that without problem.

3. There is currently no support for GCs, i.e. we do not readily export information, where pointers are. Though libFirm's type system is strong enough to contain that information, but somebody has to do the work to export this and connect it to a GC. There was not enough interest and too little manpower available to do this so far. For all projects, where a GC is used, we use a Boehm GC.

4. Yes, libFirm has a pass for this. It can even eliminate pseudo-tail calls like 'int fac(int n) { return n == 0 ? 1 : n * fac(n - 1); }'. This is no proper tail call, because the '' is the last operation, which happens (and not the call to fac()). Because '' is associative and commutative, we can still transform this into a loop. And it has many more analyses and transformations: local optimizations (aka "instcombine"), common subexpression elimination, partial redundancy elimination, scalar replacement, reassociation, implicit (due to being dependency-graph based) dead code elimination, Click's combo optimization, bitwise constant information, load-store optimization, control-flow optimization, conditional jump threading, if-conversion, operator strength reduction, division-by-constant optmization, function inlining, register-pressure aware instruction scheduling, block scheduling, belady spiller, SSA-based register allocation and copy coalescing, ...

The main points of this (i.e my) post on the mailing list still apply. Nowadays everything is even more nice. (:

One important difference to LLVM is the backend (machine code generation). libFirm uses its graph-based intermediate representation with explicit data dependencies not only in the "middleend" (i.e. for architecture-independent optimizations), but also in the backend. In contrast, LLVM uses completely different representations for the middleend and backend. libFirm still has explicit data dependencies and SSA form in code generation, which simplifies several important code-generation phases. (LLVM has a more classical virtual/physical register approach.) It's simpler from the theoretical viewpoint of compiler construction and it's also easier for engineering a compiler. E.g. it allows for decoupling spilling and register assignment. It also enables checkable register allocation, because in our representation the register assignment is just an annotation and the explicit data dependencies (which operation uses which operands) is still the primary encoding in the graph, which allows having a checker for the register allocation. SSA form gives the usual benefits that the question "what is the definition of this value?" is directly encoded in the graph and is readily available. Having the same representation as the middleend allows for reusing passes in the backend. E.g. we run the middleend's code placement (loop-invariant code motion) in the backend after instruction selection.

Also there's been a lot of work on the AMD64 backend and for example it is able to run the SPEC benchmarks. The info on the page is just a bit stale. (Note to self: Update the page)

It's sufficiently compatible to handle e.g. glibc, which is quite a feat, because it uses many and somewhat obscure gcc extensions.