IR is better than assembly (2013)

&gt; If you really can write better assembly than LLVM, please: Don&#x27;t write any more assembler by hand - write IR and create new LLVM optimisers instead. It&#x27;ll benefit everybody, not only you. Think about it - you won&#x27;t need to write the same optimisations all over again on your next project!<p>Very noble goal, but I can imagine that it can take a lot more time to do that than just writing a bunch of assembler instructions.<p>Perhaps there could be some intermediate approach, where LLVM can learn from a IR&#x2F;assembly pair and improve itself (?)

If I wanted to do this sort of thing, I&#x27;d probably use either intrinsics or C directly -- the compiler is already good at dealing with both, and will probably do a better job than LLVM IR.<p>The biggest reasons to drop to assembly is because there are high level constructs that the compiler is very unlikely to recognize and optimize effectively. Things like AES-NI, hardware RNGs, and similar.

This is neat, I had no idea there was an intermediate language like this which is cross platform. It would seem that I could decompile binaries using llvm tooling and then recompile for other platforms.<p><a href="http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;6981810&#x2F;translation-of-machinecode-into-llvm-ir-disassembly-reassembly-of-x86-64-x86" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;6981810&#x2F;translation-of-ma...</a><p>Obviously not cross os, but might be good for bare metal stuff. I&#x27;ve gotten libraries in the past compiled with weird ABIs. This sounds really neat.

The other thought I had here, is that AFAICT IR is not a standard. There is no requirement that it remains compatible in 50 years or 5 months. There is no standard IR, and shouldn&#x27;t be, as that would become an impediment to compiler evolution and fit&#x2F;optimization to newer architectures.<p>Doesn&#x27;t AS&#x2F;400 use an IR approach as well? Which let IBM seamlessly migrate the underlying CPU a few(?) times now?

Duplicate of <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=6096743" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=6096743</a> (220 comments)

The Open64 &#x2F; PathScale compiler suite has had intrinsics written in the IR (WHIRL) for a long time. WHIRL is stable enough that it&#x27;s not a maintenance problem. Being written in IR means that the full power of inlining, function specialization, etc etc will be used, even if whole-program optimization isn&#x27;t being used.

Most of the guides I&#x27;ve seen for LLVM recommend you use the LLVM libs to generate the IR. Why? I feel like it would be much easier to generate the IR directly like the author has done.<p>It also wouldn&#x27;t tie me to any particular library - I think the only actively maintained one is the C++ one.

I object to the article just associating the term &quot;IR&quot; with LLVM IR.<p>IR is short for &quot;Internal Representation&quot;. Most complex compilers have at least one level of IR, usually multiple ones that are progressively lower level.<p>The point is that an IR carries more information than machine code, and so potentially allows more specific optimizations.<p>This should at least be mentioned in the article.<p>Rust and Swift, for example, both use LLVM, but have their own intermediate levels of IR (&#x27;Mir&#x27; for Rust).<p>LLVM IR is already stripped of a lot of information that might be important for certain higher level optimizations. For example, numbers are all unsigned, and there are different operations for signed and unsigned arithmatic.

In this way, IR would fullfil the same role Macro-32&#x2F;64 did for porting VMS to Alpha and beyond. However, it appears to my understanding (sorry, I was still crawling when VAXes were on the way out), that the benefit was retaining &quot;VAX&quot; syntax to avoid massive rewrites.<p>If you&#x27;re starting from a clean slate, what&#x27;s the benefit of writing IR? Why not use C? After all, IR won&#x27;t really give you complete control over generated code, and it&#x27;s still an abstract VM (albeit that obviously allows writing IR that will only sensibly compile on a specific arch - e.g. system register acceses and so on).

It&#x27;s interesting since I proposed using LLVM in place of inline assembly a while back. I got this counter point when I asked on ESR&#x27;s blog:<p><a href="http:&#x2F;&#x2F;lists.llvm.org&#x2F;pipermail&#x2F;llvm-dev&#x2F;2011-October&#x2F;043724.html" rel="nofollow">http:&#x2F;&#x2F;lists.llvm.org&#x2F;pipermail&#x2F;llvm-dev&#x2F;2011-October&#x2F;043724...</a><p>Any LLVM experts have thoughts on this or my original goal within the context of LLVM&#x27;s <i>current</i> situation?

This may be a little off-topic but does anyone know a good and up-to-date tutorial for using LLVM in C language?

I don&#x27;t have projects that fits on this, but sounds like a no brainer. Abstracting the specifics and keeping the timeless is a beautiful move!

LLVM IR is not really suitable because of compatibility. Someone should create a portable assembler on top of LLVM instead.

What&#x27;s the difference between LLVM IR and various GCC IR&#x27;s?

TL;DR: vendor lock-in.

Yes. Let&#x27;s all write IR instead of assembly. Let&#x27;s encourage others to do the same, making Assembly even more of an ivory tower (or, more accurately, a grimy sub-basement) than it already is, further discouraging newcomers from learning it, thus keeping them from properly understanding the machines they program on. Eventually, nobody will even understand any of these machines.<p>Use whatever you want in production, I don&#x27;t care. But don&#x27;t discourage people from learning assembly. It&#x27;s a worthwhile task.

Anyone tell the LLVM team that the Babel tower is a myth and that it ends bad?<p>Some CPU have specific idioms that are not only hard to translate but requires to be used fluently. Like natural language.<p>Btw, I never uses any software relying on a name of a myth that was a pure failure such as Babel or death star. It makes me feel like people intend to fail.