Re: [Liberty-eiffel] LLVM backend status

[Raphael Mack]

Hi Paolo, hi all,

so you say the LLVM wrapper could basically be working but it's far from
being usable as compiler backend, right?

For a Liberty compiler from scratch it would be a good option to use
LLVM or a future version of GCC for a backend, but with the current
state, where we focus on maintaining the SE code and the library base we
have the LLVM code is not really relevant.

Take the time to look at the things that are there, but I think it may
be an option to move src/smarteiffel/commands/llvmec.e and
src/smarteiffel/generation/llvm/ to work/legacy until we restart the
work on the redesign...

Regards,
Rapha

Am Donnerstag, den 02.01.2014, 13:34 +0100 schrieb Paolo Redaelli:
> Il 29/12/2013 23:32, Raphael Mack ha scritto:
> 
>         Hello, let me ask the question about the state of the LLVM
>         wrappers and the Smarteiffel LLVM backend and the plans for
>         the (near *) future. Currently api doc generation fails in
>         master due to missing loadpaths... Cheers, Rapha * near means
>         the next two releases 
> 
> First of all, Happy GNU Year to anyone!
> I owe you at least an explanation for my silence which is - surprise,
> surprise - real life took its toll with a couple of unexpected tasks
> in addition to the usual efforts on an university course (Structural
> Analysis and Design for architecture students). I always understimate
> the time required for them.
> Given that, the relationships between LLVM and a GNU project are quite
> delicate, IMHO.
> I chose to "wrap" and use LLVM because it was much more easier to deal
> with, much more documented, providing a library-like, clean interface.
> At least interfacing with LLVM didn't resembled black magic like
> building a new gcc frontend. Well, it isn't really fair to call it
> black magic. Just ancient magic, as it let you feel how designs were
> made back in the 70-80 s. Which requires you to deal with c, write in
> c and use c to develop our frontend. 
> No way. We know that with the notable exception of bootstrap
> SmallEiffel, SmartEiffel and LibertyEiffel were all implemented in the
> language it compiles. 
> The fact that LLVM is released under a BSD license wouldn't have
> harmed, at least in any foreseeable future. Quite understandably this
> high quality academic project attracted the attention of many
> companies which liked the lack persistent freedom typical of BSD
> licenses so they could fork into proprietary version. 
> I'm pretty sure that it is a somehow required behaviour for an usa
> university to either patent their research or let us companies to
> leverage of that. Not that I am against making money of course!
> Luckily we have the gnu Ada compiler as an effective counterexample. 
> A couple of months ago I read that next gcc version will see a deep
> redesign of its internals, offering a much more clean, easier to
> interface with and documented api for front end writers. That is us. 
> Work is going on in the gcc repositories but I would rather approach
> them when they will have reached some milestone. 
> 
> So I think we could stick to llvm for a while. A moving target itself
> thought. 
> The example in llvm wrappers (should) build an hello world
> programmatically. I wrote it when current llvm was 2.9. I know it to
> work with 3.2 and 3.4. I don't know if more recent llvm versions will
> work
> Then there is src/smarteiffel/generation/llvm/ which is nothing more
> than a (multi-process) skeleton. The version in my github repository
> should fork a worker for each CPU and "scan" all the classes sending a
> "compile class x" to each worker; the aim is to parallelize the
> equivalent of  C emitting. 
> But it's only a skeleton.
> 
> I'm retaking some grasp on the messy code of my repository, so please
> keep hold on for some days (<10). 
> 
> Thanks in advance for your attetion
>   an overloaded (and currently sick BTW) Paolo