Hey, as far as I understand, due to the use of getHostCPUName in Mesa, Mesa breaks with an LLVM Error since it uses the new pass manager. The problem is: In virtual environments, the CPU vendor, generation and flags may not point to a real CPU. This can confuse getHostCPUName - in my case, my university uses a setup where they emulate CPU specifications similar to an Intel Westmere chip but name “AuthenticAMD” as vendor. This causes getHostCPUName to return athlon-xp and then the new pass manager to fail with LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it!.
As far as I understand at least Intels website https://www.intel.com/content/www/us/en/developer/articles/technical/optimize-llvm-code-data-analytics-vectorization.html , EngineBuilder::setMCPU with the result of getHostCPUName seems to be recommended, but that exactly causes this issue. How would one work around it? Is this virtual CPU configuration just not supported by LLVM, or can one use LLVM in a way that doesn’t break in this case?
Since this issue only occurs in Mesa since it uses the new pass manager, I’ve opened this issue as a bug report in Mesa so far ( OpenGL app fails with LLVM ERROR since Fedora 37 (Mesa 23.03) (#9442) · Issues · Mesa / mesa · GitLab ), but I’m not sure if this is more intrinsic to LLVM, hence this post.