When running on different platforms "llc --version" reports the host CPU which is used for detection by some code to work out what target to compile for (eg pocl). For x86 this reports: $ llc --version LLVM (http://llvm.org/): LLVM version 3.4.2 Optimized build. Built Aug 14 2014 (16:12:44). Default target: x86_64-redhat-linux-gnu Host CPU: corei7-avx But for ARMv7 and aarch64 for some reason it reports unknown which means things can break: ARMv7: $ llc --version LLVM (http://llvm.org/): LLVM version 3.5.0 Optimized build. Built Dec 11 2014 (17:27:57). Default target: armv7hl-redhat-linux-gnu Host CPU: (unknown) aarch64: # llc --version LLVM (http://llvm.org/): LLVM version 3.4.2 Optimized build. Built Aug 15 2014 (04:36:14). Default target: aarch64-redhat-linux-gnu Host CPU: (unknown)
Still valid with 3.6.1: $ llc --version LLVM (http://llvm.org/): LLVM version 3.6.1 Optimized build. Built Jul 6 2015 (07:08:46). Default target: aarch64-redhat-linux-gnu Host CPU: (unknown) Registered Targets: aarch64 - AArch64 (little endian) aarch64_be - AArch64 (big endian) amdgcn - AMD GCN GPUs arm - ARM arm64 - ARM64 (little endian) armeb - ARM (big endian) cpp - C++ backend nvptx - NVIDIA PTX 32-bit nvptx64 - NVIDIA PTX 64-bit ppc32 - PowerPC 32 ppc64 - PowerPC 64 ppc64le - PowerPC 64 LE r600 - AMD GPUs HD2XXX-HD6XXX systemz - SystemZ thumb - Thumb thumbeb - Thumb (big endian) x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
I tested this on armhfp with LLVM 3.9.1 and it was working.
(In reply to Tom Stellard from comment #4) > I tested this on armhfp with LLVM 3.9.1 and it was working. really? $ llc --version LLVM (http://llvm.org/): LLVM version 3.9.1 Optimized build. Default target: armv7l-unknown-linux-gnueabihf Host CPU: (unknown) Registered Targets: aarch64 - AArch64 (little endian) aarch64_be - AArch64 (big endian) amdgcn - AMD GCN GPUs arm - ARM arm64 - ARM64 (little endian) armeb - ARM (big endian) bpf - BPF (host endian) bpfeb - BPF (big endian) bpfel - BPF (little endian) mips - Mips mips64 - Mips64 [experimental] mips64el - Mips64el [experimental] mipsel - Mipsel nvptx - NVIDIA PTX 32-bit nvptx64 - NVIDIA PTX 64-bit ppc32 - PowerPC 32 ppc64 - PowerPC 64 ppc64le - PowerPC 64 LE r600 - AMD GPUs HD2XXX-HD6XXX systemz - SystemZ thumb - Thumb thumbeb - Thumb (big endian) x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 $
Which processor are you testing on?
(In reply to Tom Stellard from comment #6) > Which processor are you testing on? ARMv7 Cortex-A7
Also on a Cortex-A57 (aarch64): $ llc --version LLVM (http://llvm.org/): LLVM version 3.9.1 Optimized build. Default target: aarch64-unknown-linux-gnu Host CPU: (unknown) Registered Targets: aarch64 - AArch64 (little endian) aarch64_be - AArch64 (big endian) amdgcn - AMD GCN GPUs arm - ARM arm64 - ARM64 (little endian) armeb - ARM (big endian) bpf - BPF (host endian) bpfeb - BPF (big endian) bpfel - BPF (little endian) mips - Mips mips64 - Mips64 [experimental] mips64el - Mips64el [experimental] mipsel - Mipsel nvptx - NVIDIA PTX 32-bit nvptx64 - NVIDIA PTX 64-bit ppc32 - PowerPC 32 ppc64 - PowerPC 64 ppc64le - PowerPC 64 LE r600 - AMD GPUs HD2XXX-HD6XXX systemz - SystemZ thumb - Thumb thumbeb - Thumb (big endian) x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64
So it seems cortex-a9 reports correctly: llc --version LLVM (http://llvm.org/): LLVM version 3.9.1 Optimized build. Default target: armv7l-unknown-linux-gnueabihf Host CPU: cortex-a9 Registered Targets: aarch64 - AArch64 (little endian) aarch64_be - AArch64 (big endian) amdgcn - AMD GCN GPUs arm - ARM arm64 - ARM64 (little endian) armeb - ARM (big endian) bpf - BPF (host endian) bpfeb - BPF (big endian) bpfel - BPF (little endian) mips - Mips mips64 - Mips64 [experimental] mips64el - Mips64el [experimental] mipsel - Mipsel nvptx - NVIDIA PTX 32-bit nvptx64 - NVIDIA PTX 64-bit ppc32 - PowerPC 32 ppc64 - PowerPC 64 ppc64le - PowerPC 64 LE r600 - AMD GPUs HD2XXX-HD6XXX systemz - SystemZ thumb - Thumb thumbeb - Thumb (big endian) x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 So I'd say better but not fixed....
(In reply to Peter Robinson from comment #9) > So it seems cortex-a9 reports correctly: > > llc --version > LLVM (http://llvm.org/): > LLVM version 3.9.1 > Optimized build. > Default target: armv7l-unknown-linux-gnueabihf > Host CPU: cortex-a9 Oh and even though it reports the host cpu correctly the triple still is not.
What should the triple be?
Also, can you post /proc/cpuinfo for the systems where it doesn't work.
(In reply to Tom Stellard from comment #11) > What should the triple be? I would have thought it would be the red hat standard triplet as used in fedora/rhel but it seems that x86 reports unknown too so possibly not (or it's a separate bug). LLVM (http://llvm.org/): LLVM version 3.9.1 Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: broadwell
Mustang x-gene (Cortex-A57): processor : 0 BogoMIPS : 100.00 Features : fp asimd evtstrm CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x0 CPU part : 0x000 CPU revision : 0 AllWinner H3 (Cortex A7): processor : 0 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 48.00 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 I can cross check others later if you want a full list across all the platforms I have available but please confirm it's useful
AllWinner A20 (Cortex A7): processor : 0 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 7.57 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 4
bcm2836 (Cortex A7): processor : 0 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 bcm2837 (Cortex A53) ARMv8 aarch64 CPU running with ARMv7 32 bit OS: processor : 0 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4
Clang uses "unknown" in the triple too (of course) and so does Rust. I sort of figured this was the culture of LLVM. :) If LLVM changes, I only hope this will not affect Rust yet, because a lot of the other tooling is not ready to deal with anything but "unknown". There are a few open issues about this, to just ignore the vendor part. https://github.com/rust-lang/rfcs/issues/1763 https://github.com/rust-lang/rust/issues/33147
(I'm referring only to the unknown vendor in the triple, not the host cpu.)
The auto-detection for ARM is very simple, it just parses the output of /proc/cpuinfo and uses the CPU part number to look up the corresponding cpu string in a table. The table is missing some entries which is why it displays (unknown) for some of the ARM CPUs. However, the 'Host CPU' value returned by llc only matters if you pass the option -mcpu=native to llc or other tools. If you don't specify any -mcpu it just compiles for a 'generic' CPU for your target. It's not a good idea for applications to use llc to determine CPU type. They should use some other more reliable method or just pass -mcpu=native to llc/clang.
Well it's caused us issues in the past and hence this bug... some of the detail is documented here, some likely forgotten in the intervening time since this bug was opened in 2014 so you'll have to forgive me for that, but most of the detail should be documented above
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
The issue with POCl was fixed upstream by d7f89ad2696a253296a5116bd89fe3031de1fb1c Applications should either be using -march=native or doing their own CPU detection if they really care about optimizing for a specific CPU. Were there any applications besides pocl, which were hitting this bug?
> Were there any applications besides pocl, which were hitting this bug? Not that I can remember offhand but it was a long time ago we dealt with a lot of this, I think we're good to close this one out, anything new is likely a different issues