Why exactly can't I inline this?

[Intaris]

I know that property nodes and such prevent a VI from being inlineable ( or at least I understand why statically-linked property nodes prevent this.

I am writing to a FPGA DMA FIFO from my RT application and cannot inline the following piece of code.  (This is all that is in my VI apart from the object terminals themselves.  It's a static VI, not Dynamic Dispatch.

Why not exactly?  Is this just an over-zealous checker saying "Nope, no property nodes allowed" or is there something inherent in the call that prevents it being inlined?  I recall subroutine priority banning ann asynchronoud calls because it could not actually be interrupted.  Is this something similar?

I'm using LV 2012 SP1.

[CMal]

---

@Intaris wrote:

Is this just an over-zealous checker saying "Nope, no property nodes allowed" ...?

---

Yes, I think that's pretty much it.  In my experience, VIs cannot be inlined if they contain any sort of property or invoke nodes.

[Intaris]

But is the non-inlineability of this particular type of property node correct or a side-effect or prohibiting other types?  I guess that's my real question.  COULD this node be inlined if the IDE would have different rules or is this kind of inline operation (writing to a FPGA DMA FIFO from an RT application) inherently not allowable?

[Jacobson-ni]

I am not sure of the reason why these block diagram items are not allowed, but in the VI Execution Speed help documentation is does say that inlined SubVIs cannot have property or invoke nodes so I would guess that the problem lies more with inlining the node itself rather than writing to a DMA FIFO being the issue.

http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/vi_execution_speed/#SubVI_Overhead

[Intaris]

My curiosity requires that I keep asking..... Sorry guys, I'm not yet satisfied with the answers.  They are technically correct but don't really give me the information I'm looking for.

My current understanding is that

1) Implicit property/invoke nodes (no reference input) and invoke nodes CANNOT work when inlined because the objects to which they point will cease to exist.

2) Explicit property/invoke nodes  (reference input) can work fine in an inlined VI.  At least there's no obvious reason (to me, today 29. April 2015 08:30AM CET) why this cannot possibly function when inlined.

unless there are some synchronisation actions going on similar to subroutine setting.  Here the inability to thread swap within the sub-VI code is a reason why a host of functions cannot be run as subroutine, this I understand.

But I can take the code shown above as it is and it will execute fine if I manually place it in the parent VI.  Unchanged code, no changed context, the FPGA reference is exactly the same.

So can anyone give me technical explanation (I don't count documentation of current behaviour as a technical explanation) why explicit (with a reference input) property nodes or invoke nodes cannot be inlined.  And if it's any different, why can't FPGA DMA FIFO Writes not be inlined?  If there is no technical limitation then I will be making a request to change this behaviour to better differentiate between implicit and explicit property nodes and invoke nodes.

[tst]

---

@Intaris wrote:

I'm not yet satisfied with the answers.  They are technically correct...

---

The best kind of correct:

[Dragis]

Technically, like you mentioned, anything that does not have an explicit reference to something in that particular VI should be inlinable. It really boils down to the cost tradeoff of doing the work to make it happen. In other words, if you can copy the code from the callee into the caller and LabVIEW doesn't complain or drop really weird code along with it then it could be reasonably inlined.

Even more technically, even things that have explicit references could be (mostly) inlined by having the compiler grab references to the things in the original VI it needs access to but inlining the actual diagram. This particular case is actually useful when there's a hot trace through the VI from the caller and the other references are just status information. I've manually broken a VI specifically for this reason and wired references to the UI portions to do this same optimization.

[Intaris]

So the to change the compiler so that these "good" property nodes and invoke nodes are inlieable is at least technically feasible?

Well then, Idea exchange here I come.

[paul_cardinale]

On possible reason is that if property nodes were allowed in inlined code, it would be possible to construct a dooeway into passsword protected block diagrams.

[Intaris]

Paul, care to elaborate on that?  Current opinion is that LVs pasword protection is, to be polite, not state of the art.