LLVM and LabVIEW

[JackDunaway]

Did you happen to catch the announcement a while back (LV2010 era) that LabVIEW source was being compiled to DFIR (DataFlow Intermediate Representation) and then to LLVM IR (Low Level Virtual Machine) before being compiled to target-specific machine code?

 

Let's look at LLVM a moment; it's exciting.

 

This acronym is not just some LabVIEW R&D mumbo jumbo; the LLVM compiler is something that has cause quite a stir in the programming community for some time now.

 

In 2012 -- two years after NI R&D publicly announced that LabVIEW was leveraging LLVM -- LLVM won the ACM Software System Award. Who else has won this yearly award given to only one project? Ever heard of, say, UNIX? Java? The World-Wide Web? Eclipse? Apache? Shite -- i guess this makes LLVM A Big Deal.

 

A couple top-notch articles I've caught recently include:

 

"IR is better than assembly": https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/

"Kaleidoscope and the Lexer": http://llvm.org/docs/tutorial/LangImpl1.html

And my favorite, for the dear memories and sheer genius of this guy: "Statically Recompiling NES Games into Native Executables with LLVM and Go": http://andrewkelley.me/post/jamulator.html

 

This stuff is blowing my mind, and I'm really glad to know LabVIEW has hitched its wagon to LLVM. Keep it up, Compiler Team -- chime in here and tell us more.

[craig]

Indeed, LLVM is a fantastic compiler library; full-feaured, powerful, and well-designed.  As mentioned in the linked article, LabVIEW has been using it to implement the backend of our compiler since LV2010.

 

We hope to make even better use of LLVM's features in the future, such as improved vectorization of user G code, and supporting generating AVX instructions on supported processors, and other things.

One thing limiting our ability to fully harness the power of LLVM is compile-time performance, however.  LLVM is a lot more sophisticated than our pre-2010 legacy compiler, and takes several times longer to generate machine code.  Certain pathologically large or complex VIs can cause compile times which are unacceptably long, and this is the reason for the "compiler complexity threshold" setting which gives users a way to conditionally disable LLVM for large/complex VIs.  Unfortunately, having to continue to support our legacy compiler backend hinders our ability to fully leverage LLVM, because anything we implement using LLVM has to have an alternative way to implement without it, or be optionally disabled.  We have been researching ways to mitigate the compiler time issues, so that compile time is always linearly proportional to G code size, and hope to remove the Compiler Complexity Threshold in the future, or tweak its function to reduce optimization levels rather than disabling LLVM entirely.

 

LLVM is being constantly improved and refined by the LLVM team and the open source community, and we're excited to be able to continually draw on new features and optimizations as LLVM matures over time.