LabVIEW Compiler Design

Compiler programming is a complex topic that requires a lot of expertise even for experienced software engineers.

NI LabVIEW software is a multi-disciplinary graphical programming environment that incorporates concepts including data flow, object-oriented, and event-driven programming. LabVIEW is also multi-platform and works well with a variety of operating systems (OSs), chipsets, embedded devices, and field programmable gate arrays (FPGAs). The LabVIEW compiler is a sophisticated system that has evolved dramatically over the past 20 years. Explore the NI LabVIEW compiler process and recent compiler innovations.

LabVIEW Compiler Process

The first step in compiling a VI is to expand the class, which is responsible for resolving implicit classes into types suitable for terminal output and checking for syntax errors. After class expansion, the VI is converted from the edit model to a dataflow intermediate representation (DFIR) graph that can be used by the compiler. The compiler performs several transformations, such as dead code removal, optimizations, and preparation for code generation during the decomposition of the DFIR graph. The DFIR is then converted into a low-level virtual machine (LLVM) intermediate representation (IR), and a series of scans are run on the IR to facilitate further optimization and throttling - ultimately - into machine code.

DFIR provides a high-level intermediate representation

DFIR is a hierarchical, block diagram code, graph-based IR. Similar to G-code, DFIR consists of many nodes with endpoints that can be connected to other endpoints. Some nodes, such as block diagrams, contain graphs, which can in turn contain other nodes.

Figure 1 shows the initial DFIR for a simple VI. When LabVIEW first creates a DFIR for a VI, it is a direct translation of the G-code, and the nodes in the DFIR graph have a one-to-one correspondence like the nodes in the G-code. As the compiler executes, DFIR nodes may be moved, partially separated, or added, yet the compiler will still preserve the original features, such as the inherent parallelism of the LabVIEW code.

Figure 1. Viewing the initial DFIR graph of a simple VI

DFIR provides two significant advantages to the LabVIEW compiler:

1. DFIR separates the editor from the compiler representation - Before DFIR, LabVIEW had a single VI representation that was shared by the editor and compiler. This prevented the compiler from modifying the representation during compilation and made it difficult to introduce compiler optimizations. DFIR introduces a series of optimizations and decompositions that can greatly improve the performance of LabVIEW code, requiring only that the block diagram nodes and wires be disconnected and moved.

2. DFIR as a common connection point between the front-end and back-end of multiple compilers - Today, LabVIEW can handle many distinct tasks. Similarly, LabVIEW also provides users with multiple algorithmic modes, such as LabVIEW MathScript, C integration, simulation diagrams, and statecharts. DFIR provides a common IR that is generated by the front-end and used by the back-end, making it easier to reuse different combinations.

DFIR decomposition and optimization

Once in the DFIR, the VI runs a series of decomposition transformations to reduce or normalize the DFIR graph. After the DFIR graph is fully decomposed, the DFIR optimization pass begins. There are more than 30 decompositions and optimizations that can improve the performance of LabVIEW code. Take a close look at the simple VI shown in Figures 2 and 3, which is called the Trim Whitespace VI (Trim Whitespace.vi) from vi.lib.

Figure 2. This is the VI before any DFIR decomposition.

Figure 3. The above is the definition of the Trim Whitespace.vi structure diagram

First, Trim Whitespace.vi is inlined into the calling VI, as shown in Figure 4. Now, the unreachable code and dead code removal operations can simplify the code. The first case structure will always execute the same branch because the input is a constant value. Therefore, the remaining branches can be moved along with the entire second case structure because they are never executed. Loop invariant code motion moves the Match Pattern primitive out of the loop box, ensuring that it is only executed once, as shown in Figure 5.

Figure 4. The subVI is inlined into the calling routine, resulting in a DFIR graph equivalent to this G-code.

Figure 5. DFIR graph generated by an optimized execution [page]

DFIR backend transformation

After the DFIR graph is decomposed and optimized, the back-end transforms are executed. These transforms evaluate and annotate the DFIR graph in preparation for the final reduction to LLVM IR. The clumping routine is responsible for grouping nodes into clusters that can be run in parallel. The substitution routine identifies when allocated data can be reused and when a copy must be made. After the substitution routine runs, the allocator reserves the memory space required for the VI to execute. Finally, the code generator is responsible for converting the DFIR graph into executable machine instructions for the target processor.

LLVM provides a low-level intermediate representation

LLVM is a general-purpose, high-performance, open-source framework originally invented as a research project at Illinois State University. LLVM is widely used in academic research and industry because of its flexibility, simple API, and lack of licensing restrictions. In LabVIEW 2010, the LabVIEW code generator uses LLVM to generate target machine code. After creating the code stream from the DFIR graph, LabVIEW visits each instruction and creates an equivalent LLVM representation. The software activates various optimization passes, and finally, the LLVM just-in-time (JIT) framework creates executable machine instructions in memory. LabVIEW can now use LLVM to perform instruction synthesis, jump threading, scalar replacement of aggregates, conditional expansion, tail call elimination, loop invariant code removal, dead code elimination, and loop unrolling.

DFIR works with LLVM

DFIR is a high-level IR with parallelism, while LLVM is a low-level IR with awareness of the characteristics of the target machine. The two work together to optimize the LabVIEW code written by developers for the processor architecture so that they can be executed on the processor.

– Chris Wood

Chris Wood is a sensor software engineer working in LabVIEW at National Instruments. He holds a bachelor's degree in computer engineering from Texas A&M University.

– Craig Smith

Craig Smith is a principal software engineer at National Instruments. He holds bachelor's and master's degrees in computer science from Texas A&M University.