View compiled / optimised intermediate code

[matt.baker]

I think it would be very useful to have the ability to view the end output of the Dataflow Intermediate Representation (DFIR)  (optimised) before it's passed to the Low-Level Virtual Machine (LLVM). At the moment it's difficult to tell if certain things have been optimised, and even more difficult to know how they have been optimised.

NI LabVIEW Compiler: Under the Hood

Consider the following (horrific) example:

Does LabVIEW refactor it to the following, or is it somewhere in-between like the second image?:

Sometimes leaving things inside loops make the code look neater and easier to change in the future.

Example: reading the length of a constant string, but I'm never sure if this gets changed to a constant length value or not.

Also, for a VI using a password protected sub-VI that is marked as inlined, it would make sense to not show the optimised code for the password protected part, but instead just showing the unprotected parts with a note about it not representing the final optimisation.

---

Note: I've seen an idea that previously mentioned this marked as "declined". However, the original idea proposed existing/similar functionality to the VI Analyser with only a small section on the DFIR output, so I'm assuming that is the reason it was declined.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Compile-Advisor-Report/idi-p/1215369

[nanocyte]

Show constant folding should help some. I doubt the DFIR can be reliably represented as LabVIEW code though.

[AristosQueue (NI)]

Here is first order DFIR graph for one very simple VI. The words are all blurred out, but you can see the nodes and basic data flow paths. You can see the nodes inside the borders of the structures: a single pair of shift registers breaks apart into something like eight different nodes; tunnels can be more complex. There are many transform layers, each one adjusting the graph, until we finally emit the LLVM codes. Plowing through one of these images can take us half a day.

This is not something we are going to be productizing.

[matt.baker]

Thanks nanocyte. I only very recently started looking at the constant folding option and the show buffer allocation which helps in some cases.

Thanks AQ, appreciate the example. I didn't realise that the DFIR was completely different to the LabVIEW representation. I thought it was just a multipass optimised version in native G code and I can see why you wouldn't want to show this.

Out of interest, how well would the DFIR and LLVM cope with my example? Do you think it can resolve it to just the string representation? Just a best guess would be great.

[AristosQueue (NI)]

Matt: If you turn debugging off on the VI (in VI Properties), those values will be computed once on first call and then be constant thereafter. LabVIEW's compiler does not fold these things down directly, but it does flag the code to fold down after first call. That may change in the future, but that's how it works today.

[X.]

Looking at that snapshot reminds me why I am programming in LabVIEW, not with a text-based language...

[matt.baker]

Many thanks for the extra info, AQ.

[Darren]

Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.