Re: Why LLVM may be a step forward

Bruce M. Simpson schrieb:
> Hi,
> 
> I'll chime in with my analysis...
> 
> Garrett Cooper wrote:
>> On Sun, Jan 11, 2009 at 4:31 PM, Eitan Adler 
>> <eitanadlerlist_at_gmail.com> wrote:
>>  
>>> I never took care about GPLv2 and v3
>>>    
>>>> differences but know, this seems to come to relevance in some way.
>>>>       
>>> I don't seem to understand this.  Why should gpl v3 affect the OS?  The
>>> output of the compiler isn't affected by the license.  Is it?
>>>     
>>
>> Yes the GPLv3 is `extremely viral' when dealing with proprietary
>> innovations and features, compared to GPLv2. Hence that's why Apple,
>> Cisco, Intel, Juniper, etc are incredibly wary of licensing, and are
>> sidestepping around the whole GPLv3 issue as much as possible,
>> wherever possible.
> 
> Why LLVM is new
> 
>   I believe based on the data to hand re LLVM, that we are actually 
> seeing 2 major advances over GCC in compiler design.  LLVM, like GCC, is 
> freely available open-source software, so there is much greater chance 
> these things will take seed across the world.
> 
>   The market dominators already realise the compiler market is devalued 
> in terms of profit opportunity -- it's infrastructural monopoly, and I 
> wonder how the heck M$ still manage to profit from Visual Studio (hint: 
> support network and maintenance, same as open source).

There's a hefty price tag on VS if you want to use your results 
commercially. Also there are many "add-ons" like TFS, which are not 
exactly cheap, either.

>   But because of the need for innovation, and the licensing limitations 
> of the GPLv3, LLVM is going to get attention. The smart kids out there 
> will realise LLVM is an erm, "paradigm shift" [1] over GCC in the Robert 
> Anton Wilson sense of the phrase,  and start building tools for it, 
> fingers crossed.

You are missing the main point why it gets attention: Somebody throws 
$$$ at it, so they can afford buying manpower to develop it.

> [1] RAW described the phenomenon of "paradigm shift" in terms of waiting 
> for a current generation of scientific dogma-followers to die off before 
> a new, testable *and* experience-able theroem about reality could be 
> shared with all other humans. A bit cutting, but sometimes we have to be 
> to administer the medicine!
> 
>   The other big driver for LLVM is the fact that the GPL version 3 is 
> being pushed. LLVM offers a non-encumbering alternative.
> 
> 
> But more on those 2 major, mutally dependent, advances in LLVM:
> 
> 1. Traceability in translation.
> 
> The fact that the same LLVM compiler can build both the native objects 
> (i386 ELF in this instance) and its own low-level representation of that 
> in LLVM-space, means you have a direct chain of causality, and 
> traceability, back to the compiler front-end which was responsible 
> building the meta-models of the C++ code, for translation, at t = 0.

Non sequitur.

> If you needed to map a symbol in either translation (object vs LLVM) 
> back to the C++ code, you can do that, with the appropriate markers. 
> Doug Hofstader probably has some nice mathematics for this.
> 
> This is going to make a big difference to their time/people costs re 
> maintaining LLVM just in simple, shop-floor, "dirty hands" engineering 
> terms.

You always lose information in translation from a high-level source 
language to something low-level and optimised. You can try to retain 
pieces of information, but there's always a loss. The most basic 
examples is constant folding and CSE.

> 2. Transparency in translation.
> 
>   Whilst gcc does compile to its own intermediate representation, this 
> has never been a "lingua franca" for optimization tools to communicate 

Nobody except LLVM uses the LLVM representation either.

> -- e.g. you can't simulate L2 cache fetches easily from it, or do 
> coverage analysis. The job of intermediate representation is limited -- 

Nobody can effectively and efficiently do anything sensible with cache 
in a fully automated way in a compiler.

> it is oriented towards the GNU assembler only, and only for the 
> generation, not the analysis, of code in the higher level language 
> you're working in.
> 
>   LLVM changes this, by making it possible to translate source to LLVM 
> bit-code, a transparent representation which in [1] you can trace 
> directly back to the original C++ source code.
> 
> [Note: Whilst you can probably do these two things with GCC, you can't 
> do them out of the box, and that is where LLVM scores points.]
> 
> Strange loop
> 
>   There's a co-dependency of [1] with [2] here. Transparency in 
> translation only becomes useful if you can trace the product back to the 
> source. And on the other hand, traceability in translation is only truly 
> possible if you have a *transparent* and easily understood 
> representation which analysis tools can use too.

Which [2]? I only see [1].

> I wager this "strange loop" of improved compiler software, originates 
> from something which process engineers e.g. in agriculture and the food 
> sciences have understood for years -- and an isolated example of where 
> engineering in the physical world, can lead to better engineering in the 
> virtual world.
> 
>   e.g.: mass producing food for safe consumption depends on traceability 
> -- and the "sweet spot" temperature for any unwanted bacteria doesn't 
> generally change, thus making the measurement of whatever is going on 
> transparent -- you measure temperature of your mix, e.g. for soft 
> cheese, at all stages in the production process.

*cough* The food industry is not exactly the best analogy for best 
practices - and this is an understatement.

>   If you apply the same reasoning to compiling software in a high-level 
> language, you end up with LLVM.

high-level? LLVM? You do know what the letters LL in LLVM stand for, 
don't you? All what LLVM has are basic blocks, adds (and the other basic 
arithmetic operations), compares and jumps. There's nothing "high-level" 
about it. It's a typical IR.

>   Makes me wonder what the characters really are in LLVM, and if they 
> are in any way involved in the Food Hacking movement.
> 
> Gweeds has recently been attempting to combine programming with food 
> science:
>   http://www.foodhacking.com/

Now you totally lost me. What the hell is this about?