Hello!

I'm interested in contributing to LLVM, but I'm a rather bad C/C++ developer. I do most of my work in Ada and was wondering if there was a way to still contribute to something other than the Ada frontend.

Patrick Kelly <kameo76890@gmail.com> writes:

I'm interested in contributing to LLVM, but I'm a rather bad C/C++
developer. I do most of my work in Ada and was wondering if there was
a way to still contribute to something other than the Ada frontend.

See http://www.llvm.org/OpenProjects.html

There are quite a few tasks with no C++ required.

Since I didn’t elaborate, specifically I want to work on an Ada back-end. As I understand it, there are already C and C++ backends so it technically is possible.

I just want to make sure that theres no complaints to me writing this in Ada.

Hello Patrick,

Great to have a fellow Ada programmer around, yes there are some tasks
that really need doing !

We^[1] contributed a Ada binding to the LLVM project some months ago.
However, The binding needs to be correctly tighten into the rest of
the LLVM build system properly and it needs possibly some test cases
also.

This would be a really fantastic contribution if you could take care
of this particular project on the Ada front?
We have the intent on some day soon porting the Ada frontend to
LLVM^[2] however the above work needs to be done so the LLVM side is
'ready' for that to happen.

There is of course other projects if your not interested, but I guess
these are a things would like to be done.

Cheers,
Edward.

[1] - http://www.auroraux.org/
[2] - http://forums.auroraux.org/viewtopic.php?f=12&t=6&sid=1f7338c7bb4f5c32d69d6392b454ee3f

I meant target -.-, that was a dumb mistake.
I got an okay for both the target and frontend so, pleasure to work with you all.

Any plans to make LLVM work with Google's new language, Go?

http://www.technewsworld.com/story/Go-Go-Google-Programming-Language-68622.html?wlc=1257974768&wlc=1258041607&wlc=1258047741

That's a better question for the Go developers. AFAIK, the only thing
they rely on that isn't already in LLVM is segmented stacks, and Ian
had to add that to gcc too.

No, its up to them which backend they want to use.
Sounds like they think that GCC is super quick compared to LLVM. Looks
like another fud fart out of google to me.

No, its up to them which backend they want to use.
Sounds like they think that GCC is super quick compared to LLVM. Looks
like another fud fart out of google to me.

Edward, this is no place for comments like this.

Evan

Actually, after chatting with Ian about it, it’s more of a case of the FAQ being poorly worded than them being anti-LLVM.

If you read it closely, it says that LLVM was too slow for 6g, which is their ultra-fast, non-optimizing implementation based on the Plan9 compilers. In this case, the assertion that LLVM is slow is correct: it’s definitely slower than a non-optimizing compiler. They then later implemented an optimizing implementation, which they based on GCC because they had a team member (Ian) who is a GCC expert.

On the positive side, Ian seemed very positive and even encouraging that his GCCGo frontend might be retargettable from GCC to LLVM, so I wouldn’t rule it out as a possibility if some interested community members stepped up to do it.

–Owen

Sorry :expressionless: no bad intentions..

> No, its up to them which backend they want to use.
> Sounds like they think that GCC is super quick compared to LLVM. Looks
> like another fud fart out of google to me.

Actually, after chatting with Ian about it, it's more of a case of the FAQ
being poorly worded than them being anti-LLVM.

If you read it closely, it says that LLVM was too slow for 6g, which is
their ultra-fast, non-optimizing implementation based on the Plan9
compilers.

Indeed:

  "We also considered using LLVM for 6g but we felt it was too large and slow
to meet our performance goals." -
http://golang.org/doc/go_faq.html#Implementation

In this case, the assertion that LLVM is slow is correct: it's
definitely slower than a non-optimizing compiler.

I'm *very* surprised by this and will test it myself...

Compared to a compiler in the same category as PCC, whose pinnacle of optimization is doing register allocation? I’m not surprised at all.

–Owen

In this case, the assertion that LLVM is slow is correct: it’s

definitely slower than a non-optimizing compiler.

I’m very surprised by this and will test it myself…

Compared to a compiler in the same category as PCC, whose pinnacle of optimization is doing register allocation? I’m not surprised at all.

Though, at -O0 llvm’s goal is not to optimize but to be fast, no?

I was certainly wondering what would prevent LLVM from being as fast as the go compiler. Do they need to be able to stream code from the front to middle to back ends or something? (Can llvm do that?)

I thought -O0's only use was to be ipsis literis with the code so you
can debug the application... I can't see any other use for that...

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

>> In this case, the assertion that LLVM is slow is correct: it's
>> definitely slower than a non-optimizing compiler.
>
> I'm *very* surprised by this and will test it myself...

I've tested it and LLVM is indeed 2x slower to compile, although it generates
code that is 2x faster to run...

Compared to a compiler in the same category as PCC, whose pinnacle of
optimization is doing register allocation? I'm not surprised at all.

What else does LLVM do with optimizations turned off that makes it slower?

I haven't looked at Go at all, but in general, there is a significant overhead to creating a compiler intermediate representation. If you produce assembly code straight out of the parser, you can compile faster.

Even though LLVM does little optimization at -O0, there is still a fair amount of work involved in translating to LLVM IR.

Jon Harrop wrote:

  
    
In this case, the assertion that LLVM is slow is correct: it's
definitely slower than a non-optimizing compiler.
        
I'm *very* surprised by this and will test it myself...
      

I've tested it and LLVM is indeed 2x slower to compile, although it generates 
code that is 2x faster to run...

  
Compared to a compiler in the same category as PCC, whose pinnacle of
optimization is doing register allocation?  I'm not surprised at all.
    

What else does LLVM do with optimizations turned off that makes it slower?
  

My guess would be primarily (1) respectable instruction selection, followed by (2) good register allocation. But at some point, the overhead of going through an abstract IR will slow you down. You’re never going to beat a splat compiler except with another splat compiler.

John.

Jon Harrop <jon@ffconsultancy.com> writes:

[snip]

Compared to a compiler in the same category as PCC, whose pinnacle of
optimization is doing register allocation? I'm not surprised at all.

What else does LLVM do with optimizations turned off that makes it slower?

On my experience, optimization is not the slowest part, native codegen
is. (But it could be argued that native codegen is slow because it tries
to produce the most efficient native code out of the llvm bitecode.)

Bob Wilson <bob.wilson@apple.com> writes:

What else does LLVM do with optimizations turned off that makes it
slower?

I haven't looked at Go at all, but in general, there is a significant
overhead to creating a compiler intermediate representation. If you
produce assembly code straight out of the parser, you can compile
faster.

Not for me. Producing LLVM IR is *very* fast, faster than producing
poorly optimized assembler code (I know, I do both things).

Even though LLVM does little optimization at -O0, there is still a
fair amount of work involved in translating to LLVM IR.

As said on my previous message, the most significant part of the work is
in generating native code from the LLVM IR.