Re: [Vala] GSOC Idea: LLVM Backend?

[Luca Bruno <lethalman88 gmail com>]

Il 29/04/2013 11:05, pancake ha scritto:
> On 04/29/13 10:11, Luca Bruno wrote:
> > Il 29/04/2013 10:02, pancake ha scritto:
> > > I think that having llvm backend instead of C will fix a lot of bugs
> > > related to keyword, C macro collision and others, which cannot be
> > > fixed by using the current approach. Also, compile times will benefit.
> > > I doubt about runtime performance will be a point here.
> > >
> > > One of the favorable points of Vala is that it is suposed to generate
> > > readable C code, which is probably the best transpiler i've seen out
> > > there on this topic. But having the llvm backend will duplicate this
> > > work.
> > >
> > > And this is the reason why the POSIX backend was removed, as well as
> > > other attempts to make Vala generate C++ or ObjC code (already done in
> > > some forks).
> > >
> > > There are 674 opened bugs in bugzilla, and the number only seems to
> > > grow over the time. Many of them just need some feedback and that's
> > > really annoying to me because the language is suposed to be stable for
> > > at least 2 years and only minor bindings fixes appears on every 
> > > release..
> >
> > This is not going to be fixed with an llvm backend. The C name collision
> > are fixable with a quite simple rewrite, not to say it's not a critical
> > issue, and it's simpler than rewriting the backend for llvm.
>
> Really? It is easier to make a C parser to parse all include files and 
> C files used when compiling a Vala file than using a code generation 
> engine that does not uses them?
>
> There are several bugs related to this issue and I dont think is 
> something easy to fix while Vala generates C. I only believe that this 
> is an issue for new Vala users which don't know those restrictions and 
> get "strange errors" because their Vala code generated stuff.
Yes, with the current approach you can't check all the symbols, but can 
you point me to a bug where the conflict happens in a non-trivial way 
with some foreign header?
> NOW:
>
> parse vala -> generate ast -> create C -> fork gcc -> parse C -> 
> generate ast -> optimize -> generate bin
>
> LLVM:
>
> parse vala -> generate ast -> optimize -> generate bin
>
> its not about replacing ccode for llvm, its about not rebuilding the 
> same ast twice with all the complexity of the C syntax and 
> preprocessor rules.
Please let's talk about real projects with intermediate generate object 
files, not toy programs compiled by valac.
Also, you can't directly generate an llvm ast, so:

parse vala -> generate vala ast -> generate llvm ast -> generate object 
files.

Currently it's:

parse vala -> generate vala ast -> generate ccode ast -> generate C 
files -> generate object files.

Compiling .c into .o is quite fast, what's very slow is the vala ast -> 
ccode ast thing, and what I'm asking is whether -> llvm ast will be 
faster instead. Not to say it's such a huge change that it's not viable 
for a gsoc. Also, by switching to llvm you're basically dropping the 
possibility of using different compilers (for example I often use tcc on 
my eeepc), while generating the C code means a lot of flexibility in 
that regard, including ccache.

Best regards,