licence

Posted Apr 28, 2010 0:28 UTC (Wed) by coriordan (guest, #7544)
In reply to: licence by daglwn
Parent article: LLVM 2.7 released

Maybe you took "catch-up" as a put down for the project. That's not how I meant it. I meant it in terms of adoption, readiness for adoption as judged by third-parties. Whatever about LLVM comparing well or badly in various ways to GCC, the current situation is that virtually every project uses GCC, and almost none use LLVM. Before LLVM becomes the pace setter, it first has to get to a stage where projects and distributions migrate in large numbers from GCC to LLVM.

It's not there yet. A proprietary extension that squeezes out a 10% speed increase is currently not very valuable because the software isn't used. When the software is widely used, then a 2% speed increase will be noteworthy. A that point, the commercial developers will keep their special sauce secret and projects and distros will be asked to choose between shipping slower binaries, or shipping faster binaries that can't be modified/recompiled without losing the speed increase.

That's a problem that's coming.

licence

Posted Apr 28, 2010 3:41 UTC (Wed) by daglwn (guest, #65432) [Link] (3 responses)

How do you define "being used?" There are many companies using LLVM in products. It's not widely used by open source projects, perhaps, but your argument assumes that companies worry about their IP being used by open source projects. The worry, if there is one, is that competing companies will use the IP. Since multiple companies are already using LLVM, it seems this is not a big concern.

The primary issue is not contributing code. It's being able to link to other software.

licence

Posted Apr 28, 2010 20:41 UTC (Wed) by man_ls (guest, #15091) [Link] (2 responses)

Why is it that companies shouldn't be able to link a GPL compiler to other software, like proprietary modules? As long as it is only used in-house there is no problem at all, and I would guess that is the primary use case for 99% of users. Particularly for a compiler: you enhance it, you use it to compile your software, you distribute the result. (All libraries used by compiled code should be under a different license, of course, just like with GCC.)

Those that want to distribute or sell their proprietary modules along with the compiler cannot, and that is exactly Ciaran's point: a company cannot make a business of selling proprietary enhancements.

licence

Posted Apr 29, 2010 4:46 UTC (Thu) by Thalience (subscriber, #4217) [Link] (1 responses)

I think the point is that LLVM is not just a compiler. It is a toolkit. Producing a proprietary module to enhance the code generation (or whatever) is possible, sure. Although I think that trying to go head to head with Intel's ICC on the proprietary compiler front is a (badly) losing proposition. Anyone who wants a proprietary compiler already has one.

The real interesting cases where someone might want to link parts of LLVM to proprietary code are things like using the JIT compilation infrastructure as part of the AI for a commercial game. Or the MC toolkit for binary analysis of some kind. Where the end product is not really a compiler in any traditional sense of the word.

licence

Posted Apr 29, 2010 7:58 UTC (Thu) by nix (subscriber, #2304) [Link]

ClamAV 0.96 already does this, with a signed bytecoded language for writing downloadable detectors in, compiled to native code by LLVM, and compiled from a subset of C into the bytecode by LLVM as well.