LabVIEW
Labview on Win 10 ARM 64 on Raspberry PI
Just to throw more wood on the fire:
QD,"Execute:SSE Runtime Optimization",CTRL+SHIFT+B should get you that property, even if scripting magic is off.
You'd have to 'VI Server' this for all VIs in a build, I guess.
This might be a way to get it done in >LV16. SSE could be a requirement of the RTE though...
Search LabVIEW like a graph! 
Thanks for the hint.
But even if you disable the following option:
The error is still shown.
I've tried several more or less dodgy ways to disabled the SSE option, but the actual compile sub programm deep within the labview compile process has this option missing. Therefore is not possible to do it from my point of view...
Yes, I seem to remember that the LabVIEW 2017 compiler actually lost the ability to disable code generation for SSE for floating point arithmetic. It may actually have something to do with the used LLVM compiler. Disabling SSE and SSE2 for AMD64 is considered unneeded since every AMD64 compatible CPU has guaranteed SSE/SSE2 support (except it seems the x86/x64 emulation in the Windows ARM build). And it seems LLVM eventually removed that possibility altogether.
This is a long (long, long) shot... Probably another red haring.
For a project (LV18) I have to set MKL_DEBUG_CPU_TYPE = 5 as a system variable.
Apparently, this fixes some compatibility between Intel and ARM CPUs. For me it's mostly lvanlys.dll that won't work properly if this variable isn't set.
This comment in that thread:
"The detail, that the slow non-intel path uses SSE, while the faster path (triggered by MKL_DEBUG_CPU_TYPE=5) uses AVX2 is probably worth mentioning...", makes me thing there is a slim change it makes some difference.
You don't mention what version you used. For my situation, this should be fixed from LV20 on higher. The variable might still do something useful when simulating Intel on a ARM...
Again, a long shot... But hopefully a quick test?
@Cheaterlow wrote:
I had to google how to set this up right. Please correct me if i have done this wrong.
open cmd and type: "MKL_DEBUG_CPU_TYPE=5", leave the cmd open.
Restart Labview and compile it again.
The outcome is the same iam still getting the 0x464 with SSE issue.
Btw. iam using LV2020.
Thanks for the tips and suggestions 🙂
How to Set Environment Variables in Windows 11/10 (aomeitech.com)
You can add a key to the registry as well:
HowTo: Set an Environment Variable in Windows - Command Line and Registry - Dowd and Associates
You are all barking up the wrong tree here. The real problem is that the LabVIEW built in compiler (based on LLVM) has lost the ability to generate code that will NOT use SSE/SSE2/AVX instructions with version 2017.
The MKL issue is entirely separate from that and in fact the opposite. lvanlys.dll is a thin wrapper around the Intel MKL library. This library can correctly detect what Intel CPU is present and enable different algorithm code paths that make maximal use of the CPU features. But this detection logic fails (not very surprisingly) with certain modern AMD CPUs. And instead of falling back to the minimum possible support such as only Pentium features, it hangs up in the detection routine. Setting the environment variable tells the detection routine that the system knows better what CPU features to use than its own detection logic and simply skips most of the detection altogether. Setting this environment variable to a value of 5, tells the MKL basically: "Don't worry I know that the CPU supports SSE, SSE2, AVX and AVX2 and you don't have to try to detect that. Just go ahead and assume I tell you the truth!"
On an x86 emulation in Windows ARM, this would be exactly the wrong thing to do. However, since the compiled LabVIEW code can't even initialize as it tries to setup the non-existing SSE registers, this is a moot point anyways.
