Compiler is Too Smart for My Own Good

[Intaris]

I'm referring to the original post. And this is just my opinion, but I would have thought we'd all be in the same page to be honest.

Bypassing structure with a wire passed through it due to compiler decisions is, in my opinion, not acceptable without clear visual feedback so that the programmer sees what's going on at the very least.

I would prefer the compiler to NOT override my specific decisions with regard to dataflow. If compiler optimisations change, this could have severs implications on the execution of the code.

There may well be some corner cases which require care, such as individual frames of a sequence structure, but focussing on any single frame, the dataflow should be maintained as programmed.

[Yamaeda]

If this an opportunity to use 'always copy' in the case as to have it make something. It's been used for similar things previously. I'd consider it a bug in that it doesn't adhere to structure bounds in the optimization. From a pure optimization standpoint i'd say it's correct.

[paul.r.r]

100% a bug and I don't understand how anyone could suggest any differently. 

That said, I can't actually replicate this behavior - can anyone else? 

[Mark_Yedinak]

---

@Intaris wrote:

I'm referring to the original post. And this is just my opinion, but I would have thought we'd all be in the same page to be honest.

Bypassing structure with a wire passed through it due to compiler decisions is, in my opinion, not acceptable without clear visual feedback so that the programmer sees what's going on at the very least.

I would prefer the compiler to NOT override my specific decisions with regard to dataflow. If compiler optimisations change, this could have severs implications on the execution of the code.

There may well be some corner cases which require care, such as individual frames of a sequence structure, but focussing on any single frame, the dataflow should be maintained as programmed.

---

I am in complete agreement with you. This completely violates data flow. The code syntax very clearly indicates the FP.close should be invoked after the case has completed execution. Any optimization that changes the explicit data flow should not be occurring. Optimizations could change the order of operations of parallel nodes that have no data dependency between them but it should never override explicitly defined data flow.

[altenbach]

Yes, the original observation is definitely a bug. Dataflow needs to define execution order and that cannot be "optimized" out. It could well be a bug that has already been fixed in newer versions (or did not exist in previous versions). I'll play around a bit....

[billko]

---

@Mark_Yedinak wrote:

---

@Intaris wrote:

I'm referring to the original post. And this is just my opinion, but I would have thought we'd all be in the same page to be honest.

Bypassing structure with a wire passed through it due to compiler decisions is, in my opinion, not acceptable without clear visual feedback so that the programmer sees what's going on at the very least.

I would prefer the compiler to NOT override my specific decisions with regard to dataflow. If compiler optimisations change, this could have severs implications on the execution of the code.

There may well be some corner cases which require care, such as individual frames of a sequence structure, but focussing on any single frame, the dataflow should be maintained as programmed.

---

I am in complete agreement with you. This completely violates data flow. The code syntax very clearly indicates the FP.close should be invoked after the case has completed execution. Any optimization that changes the explicit data flow should not be occurring. Optimizations could change the order of operations of parallel nodes that have no data dependency between them but it should never override explicitly defined data flow.

---

Not only a "bug", but a scary one.  We should at least be made aware of compiler optimizations of this nature, like it reminds us about folding constants and Boolean constants connected to case structures.

[mcduff]

---

@Mark_Yedinak wrote:

---

@Intaris wrote:

I'm referring to the original post. And this is just my opinion, but I would have thought we'd all be in the same page to be honest.

Bypassing structure with a wire passed through it due to compiler decisions is, in my opinion, not acceptable without clear visual feedback so that the programmer sees what's going on at the very least.

I would prefer the compiler to NOT override my specific decisions with regard to dataflow. If compiler optimisations change, this could have severs implications on the execution of the code.

There may well be some corner cases which require care, such as individual frames of a sequence structure, but focussing on any single frame, the dataflow should be maintained as programmed.

---

I am in complete agreement with you. This completely violates data flow. The code syntax very clearly indicates the FP.close should be invoked after the case has completed execution. Any optimization that changes the explicit data flow should not be occurring. Optimizations could change the order of operations of parallel nodes that have no data dependency between them but it should never override explicitly defined data flow.

---

Maybe the optimization should apply only to "non-UI type" wires, ie, references to property nodes. Yes I agree it violates dataflow, and "breaks" every rule LabVIEW stands for, but the optimization may be useful for other use cases that are not considered here. I would hate to lose optimizations when the work-around is only necessary for a few specific cases.

[Mark_Yedinak]

---

@mcduff wrote:

---

@Mark_Yedinak wrote:

---

@Intaris wrote:

I'm referring to the original post. And this is just my opinion, but I would have thought we'd all be in the same page to be honest.

Bypassing structure with a wire passed through it due to compiler decisions is, in my opinion, not acceptable without clear visual feedback so that the programmer sees what's going on at the very least.

I would prefer the compiler to NOT override my specific decisions with regard to dataflow. If compiler optimisations change, this could have severs implications on the execution of the code.

There may well be some corner cases which require care, such as individual frames of a sequence structure, but focussing on any single frame, the dataflow should be maintained as programmed.

---

I am in complete agreement with you. This completely violates data flow. The code syntax very clearly indicates the FP.close should be invoked after the case has completed execution. Any optimization that changes the explicit data flow should not be occurring. Optimizations could change the order of operations of parallel nodes that have no data dependency between them but it should never override explicitly defined data flow.

---

Maybe the optimization should apply only to "non-UI type" wires, ie, references to property nodes. Yes I agree it violates dataflow, and "breaks" every rule LabVIEW stands for, but the optimization may be useful for other use cases that are not considered here. I would hate to lose optimizations when the work-around is only necessary for a few specific cases.

---

Completely disagree. If I as the programmer ran the wire through a structure (case, loop, frame, whatever) and that wire is untouched within the structure the node connected to it should NEVER execute before that structure is complete. It violates every rule of data flow. Maybe I had very explicit reasons I wanted that executed after the structure node and that is why I ran the wire through. I, as the developer, imposed data flow to the code. If the compiler is free to violate that than what else will it "optimize" on me? I can very easily solve this particular optimization myself by NOT running the wire through the structure. Leave the decision to me. If it really doesn't matter when it executes and I created some inefficient code that is on me. This is a fundamental syntax of the language. The compiler should not change my data flow. NEVER!

[mcduff]

---

@Mark_Yedinak wrote:

---

---

If the compiler is free to violate that than what else will it "optimize" on me? I can very easily solve this particular optimization myself by NOT running the wire through the structure. Leave the decision to me. If it really doesn't matter when it executes and I created some inefficient code that is on me. This is a fundamental syntax of the language. The compiler should not change my data flow. NEVER!

---

It optimizes multiple things, memory, thread management, constant folding, etc. (That is one reason why we like LabVIEW over low-level languages like C.) Obviously in the example provided, the optimization does not work correctly. I do not know how long the optimization has been around, maybe it's new, maybe not, but just now has an example been brought to light that shows problems with the optimization. What will happen to existing code/performance if the optimization is no longer there?

Below is screenshot from deep within the General Error Handler. Not sure if this optimization still applies or not, but it is an example of another optimization imposed on the programmer.

[paul.r]

That's not an optimization that breaks the fundamental paradigm of the language.

Has anyone else actually replicated this? I'm not convinced this actually occurs.