Re:Firm: a C library with graph-based IR suitable for compilers
by ericfrederich on Monday January 18, 2016 @12:15PM
(#10925490)
Differences between this and LLVM? I feel it should at least be mentioned on their page.
[ Parent
| on HN ]
Re:Firm: a C library with graph-based IR suitable for compilers
by dyspept0r on Monday January 18, 2016 @01:22PM
(#10925898)
There's also this mail in the freebsd list archives on the subject. Not sure how current it is, but it gives more names of algorithms and people in case one wants to dig deeper. https://lists.freebsd.org/pipermail/freebsd-hackers/2008-Nov...
Re:Firm: a C library with graph-based IR suitable for compilers
by Rotluchs on Monday January 18, 2016 @01:52PM
(#10926074)
The main points of this (i.e my) post on the mailing list still apply.
Nowadays everything is even more nice. (:
Re:Firm: a C library with graph-based IR suitable for compilers
by UniQP on Monday January 18, 2016 @12:17PM
(#10925502)
Documentation->LLVM: http://pp.ipd.kit.edu/firm/LLVM ;-)
Re:Firm: a C library with graph-based IR suitable for compilers
by zokier on Monday January 18, 2016 @01:26PM
(#10925934)
It might be interesting to use LLVM as a backend to Firm, especially considering that two most important backends (ARM and amd64) are "in very early phases"
Re:Firm: a C library with graph-based IR suitable for compilers
by Rotluchs on Monday January 18, 2016 @01:48PM
(#10926056)
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)