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.