ALLVM: Forthcoming Project to Ship All Software As LLVM IR

[starshipeleven]

Because you can do link-time-optimizations. Meaning you optimize natively to your microcode.

We need a Gentoo veteran to speak on possible gains on this.

[orome]

Because you can do link-time-optimizations. Meaning you optimize natively to your microcode.

Every part of that sentence is either wrong or incorrect. Binaries target ISA not microops. LTO does not mean that you're targeting native ISA. You don't need to compile on target host to use LTO.

The advantage is that you can optimize for host ISA (new instructions, different instruction latencies) without shipping plethora of binaries, or using runtime feature detection/codepath selection.

[jhenke]

The obvious benefit is that you can make use of all processor features in your CPU. If you compile generic x86-64 code, you can only assume the processor running the code later to have at least SSE1 & SSE2 extensions. Everything that comes after that might or might not be present. So most vendors end up compiling for reasonable subset of processor extensions, but to not exclude possible customers that is generally very conservative.

If you want to take advantage of more recent extensions, say AVX2, the vendor either has to provide alternative binaries, exclude everyone who does not have that extension or have different code paths in the same binary with runtime detection. But compiling and linking the binary on the system it will later run removes the problem, you can simply make use of every available extension.

[Xelix]

The concept behind the idea is nothing new - Java, MSIL, etc. but using LLVM's IR, you can use any language you want, you're not constrained to Java, C# or whatever.

There are many language implementations other than Java and C# that already target the Java and .NET VMs.

[cj.wijtmans]

We need a Gentoo veteran to speak on possible gains on this.

just compare clearlinux to ubuntu and add another small difference.

[karolherbst]

EDIT: Architecture independence is also a pretty sweet.

only problem, it won't work, cause you have already symbol references and stuff like that. So if your code calls _fpow_x86_opt, it calls this, and it would fail to compile on arm, cause on arm you wouldn't have that symbol anywhere. Memcpy also has multiple opts for every thinkable platform, even multiple ones for x86.

In the end you would have to abstract all those architecture specific opts away and I didn't even mention OS specific things, short: LLVM isn't really suited for this

Anyway this idea is far from being new and I already played with LLVM IR binaries like 6 years ago.

[tessio]

I remember reading that Google or Apple uses something like this to not be 100% in the hands of ARM. This way it's possible to change CPU ISA without breaking software.

[jakubo]

if i understand this correctly: it's time for another round of compiler tests. If there is to be a benefit for having to compile the program every single time (or even once on every computer) then there should be a countable performance gain. or is it more about cutting development time/energy for programming in whatever you please..?

[Ardje]

Sounds good. ISA independent binaries. If also the supporting libraries behave, it would be neat, to run most code natively.
Dalvik and pnacl have shown it's a good thing.

[janisozaur]

Isn't it what PNaCl is?

https://developer.chrome.com/native-client/nacl-and-pnacl#portable-native-client-pnacl