Why can't I inline a VI that has an Expression Node on the BD?

[GuenterMueller]

I am just wondering why inlining is not that straightforward as it could be.  Just put an expression node on a block diagram and wire it, like in the provided PNG.  As soon as you set to VI properties to inline the code, you will notice that LabVIEW rejects inlining ...

By the way, a similar discussion (which I didn't want to highjack) is here.

I expected LabVIEW's compiler chain to do better.

[GuenterMueller]

Just checked it out: It comes as no surprise that Formula Nodes are affected the same way.

[JÞB]

Formula nodes can contain asynchronous routines.  They cannot be inlined.  

Why would you expect the LabVIEW compiler to optimize C?  It's not G code.

[GuenterMueller]

Since that piece of code should somehow reach LLVM I see no contradiction.

In turn, Jeff:  Why shouldn't it inline?  It's just some code that you and me (and many others, too) can easily place on a caller's diagram ...

[rolfk]

The inlining happens long before the LLVM stage, and even before the DFIR to LLVM generation. At that stage the inlining algorithme has no idea about what the "external code" might or might not include in terms of asynchronous code or other possible complications. And it's probably very hard to have the expression node or formula node have the code put through the C to LLVM compiler (aside that the formula node is not exactly full C anyways) and then get from that all the necessary hints to let the LabVIEW G code to DFIR conversion get enough information to decide that it is safe to put the generated code sequence into an inlined VI so the quick approach is to simply be better safe than sorry.

Basically I doubt that LabVIEW currently even has a LLVM to DFIR backannotation step that would allow to put the formula node code through the C to LLVM compilation and then backannotate it into DFIR to let LabVIEW add it into inlined code. The DFIR to LLVM conversion in itself is already a pretty complicated but necessary piece of translation, but the inverse is likely even more complicated and not really necessary except for this kind of exotic features.

[GuenterMueller]

Thanks for sharing your thoughts on DFIR and LLVM. Maybe I wasn't lucky in bringing LLVM in here as I actually didn't expect the expression node to get directly passed to it.
However, an answer to my question might have been given by Jeff who mentioned, that "Formula nodes can contain asynchronous routines.". Would anyone like to give an example of a formula node with an asynchronous node? I've strengthened my mind but could not find an example ...

[altenbach]

I have reported this a couple of months ago in private elsewhere. Even if it turns out that there is no easy fix to allow inlining VIs containing expression|formula nodes (maybe there is!?), this limitation should be mentioned in the help for these nodes (expression, formula) or in the help for inlining.

[JÞB]

---

@GuenterMueller wrote:

Thanks for sharing your thoughts on DFIR and LLVM. Maybe I wasn't lucky in bringing LLVM in here as I actually didn't expect the expression node to get directly passed to it.
However, an answer to my question might have been given by Jeff who mentioned, that "Formula nodes can contain asynchronous routines.". Would anyone like to give an example of a formula node with an asynchronous node? I've strengthened my mind but could not find an example ...

---

Sleep.  I could use some.  But that isn't what I meant.

Also. Ints are ints.  Lord Queue only knows what would happen if a refnum was a variable.

It may be one of those times when R&D is saving us from ourselves.  I really don't like shooting myself in the foot... I can aim a but sometimes even my feet are too big. 😄

[GuenterMueller]

So Christian already observed and reported this, fine.

Thank you all for your valuable feedback.

[JÞB]

Of course, you can write the same fomulae in G and inline fine.