[Ecls-list] LLVM backend?

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Sun Dec 27 08:55:37 UTC 2009

On Sat, Dec 26, 2009 at 9:44 PM, Marko Kocić <marko.kocic at gmail.com> wrote:

> I just came across some mails from about a year ago about LLVM back
> end in ECL. Is this idea still viable? Also, what is the status of new
> compiler implementation?

As of these days I am just making sure both compilers can coexist and that
ECL is able to build itself using the new one. The last part is not yet done
and no code has yet been pushed to the main repository. I will not do that
until I get some stability.

The new compiler is much better structured than the old one. It consists on
a kind of "parser" layer that builds an intermediate representation which is
a merge between the current interpreter and the old compiler's C1FORMs.

The advantage is that now this intermediate representation is linear: just a
list of forms, instead of a nested and very complicated graph. This simpler
structure is much much easier to process. Eliminating unused variables and
forms without side effects is about 10 lines. Creating the code graph and
eliminating dead code chunks will be just as simple. It will also help me in
concentrating, simplifying and better rationalizing the code for deciding
variables representations, etc.

After all that pre-processing, which is really optional, a final backend
produces the C code. This is yet the ugliest part of it all and needs to be
reorganized, but that is just a consequence of how I have incrementally
developed the new compiler -- instead of just pushing in the code in my blog

My goals are, right now,

* Make ECL build itself and pass all tests
* Push the code into the repository
* Improve type inference, which is broken in the new representation
* Improve decisions based on unboxing
* Code graph and dead code elimination
* Reorganize the backend in a separate package and a smaller set of files

A longer term plan

* A pass to build SSA code, that is, ensuring static-single-assignment by
introducing new temporaries
* A new backend for LLVM
* A new backend for the interpreter

Hope this answers some of your questions about the future. I think that once
Step 1 is done, anyone willing to could collaborate in the project.


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20091227/f35dba4b/attachment.html>

More information about the ecl-devel mailing list