4 ms·

Differences between this and LLVM? I feel it should at least be mentioned on their page.

by ericfrederich 11y ago

UniQP 11y ago
Documentation->LLVM: http://pp.ipd.kit.edu/firm/LLVM http://pp.ipd.kit.edu/firm/LLVM ;-)
- zokier 11y ago
  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"
  - Rotluchs 11y ago
    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)
dyspept0r 11y ago
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-November/026848.html https://lists.freebsd.org/pipermail/freebsd-hackers/2008-Nov...
- Rotluchs 11y ago
  The main points of this (i.e my) post on the mailing list still apply. Nowadays everything is even more nice. (:

Differences between this and LLVM? I feel it should at least be mentioned on their page.

UniQP 11y ago

Documentation->LLVM: http://pp.ipd.kit.edu/firm/LLVM http://pp.ipd.kit.edu/firm/LLVM ;-)

zokier 11y ago
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"
- Rotluchs 11y ago
  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)

dyspept0r 11y ago

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-November/026848.html https://lists.freebsd.org/pipermail/freebsd-hackers/2008-Nov...

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