craig

I just became aware of this thread and I'm not going to go back and comment on all the discussion points that have been made before, except to say: The original code which did not use a shift register was wrong, but happened the work because of a bug in the LabVIEW inplaceness algorithm. Any input tunnel should retain its original value of every iteration of the loop, so it should've stayed not-a-refnum every time, and therefore the dynamic registration should should have been lost where the loop iterated. The issue was that the left dynamic registration terminal (which is always in-pl

This DAbort has to do with trying to access Event Data for an event after the event's refcount has gone to zero and it has been deleted. This is one of those "shouldn't ever happen" kind of situations, so we'd be very interested in what you are doing to generate the error. Perhaps your QMH nesting also involves nesting Event structures themselves, possibly operating on the same event queues? If you could post your VIs, or even better, a simplified test case, I'll fire a CAR with that information and make sure it gets investigated. Thanks Craig Smith LabVIEW R&D

Indeed, LLVM is a fantastic compiler library; full-feaured, powerful, and well-designed. As mentioned in the linked article, LabVIEW has been using it to implement the backend of our compiler since LV2010. We hope to make even better use of LLVM's features in the future, such as improved vectorization of user G code, and supporting generating AVX instructions on supported processors, and other things. One thing limiting our ability to fully harness the power of LLVM is compile-time performance, however. LLVM is a lot more sophisticated than our pre-2010 legacy compiler, and takes severa