Re: [Vala] GSOC Idea: LLVM Backend?

[pancake <pancake youterm com>]

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.

> Also all the opened bugs are not going to be solved by the llvm backend,
> if you think so, please provide a plan for that.

Obviously I was not trying to say this. A new backend will not fix all 
the bugs, but I was just trying to explain my feeling on that topic 
(maybe i should did it a separate thread) so ignore this offtopic.

> The POSIX backend was removed because Vala is too gobject centric.
> Having classes and structs to work seamlessly for plain posix would
> require additional runtime code which is not the purpose of Vala, or at
> least not without a clear plan.

Yep I understand that

> Also I'd like to know in what ways compile time would benefit, since
> you're going to replace the ccode tree with an llvm tree, I don't seem
> to find such a convenience.

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.


> Also notice that llvm api is c++ (and unstable), so our beloved compiler
> can't be written in vala itself. The clang C api is incomplete.

Which parst of the C api are not complete? there's already a Vapi for 
that. And i cant find any todo or status list of missing parts for it.

http://gitorious.org/llvm-vapi

I'm not saying that Vala should move to LLVM, i was just trying to 
expose the benefits and problems that this will create.

Vala current design is pretty nice and the visitor pattern really 
simplifies the code generation and it's designed to create C code, 
making it work with LLVM will force Vala to work with a single C engine 
and will require to change all the internals of the compiler to avoid 
creating multiple ASTs and this is probably too much work for a 
questionable benefit (portability, dependence on llvm, forced to use 
llvm, etc...).

--pancake