[Ecls-list] LLVM backend?

[Marko Kocić]

Thanks for the info on ECL progress. I can't wait to play with the new
stuff, since I hope I'll finally get a chance to use CL in a "real"
project.

One more questin about LLVM backend, is it going to remain C backend
that uses clang, or LLVM itself will be used for code generation? As
nice and portable C generation is, it might be possible to gain much
in performance without sacrificing portability by using LLVM for
native code generation in compiler.

Btw, do you use some publicly accessibl repo for WIP stuff?

Regards,
Marko Kocić

On Sun, Dec 27, 2009 at 9:55 AM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> 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.
> Juanjo
> --
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
> http://juanjose.garciaripoll.googlepages.com
>