Bug 1175024 - llvm doesn't report host processor on arm* platforms
Summary: llvm doesn't report host processor on arm* platforms
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: llvm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tom Stellard
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Tracking
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2014-12-17 01:52 UTC by Peter Robinson
Modified: 2017-08-30 23:33 UTC (History)
10 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2017-08-30 23:33:41 UTC


Attachments (Terms of Use)

Description Peter Robinson 2014-12-17 01:52:15 UTC
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)

Comment 1 Marcin Juszkiewicz 2015-07-20 09:23:51 UTC
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

Comment 2 Fedora End Of Life 2015-11-04 11:04:46 UTC
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.

Comment 3 Jan Kurik 2016-02-24 13:18:13 UTC
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

Comment 4 Tom Stellard 2017-03-17 23:32:30 UTC
I tested this on armhfp with LLVM 3.9.1 and it was working.

Comment 5 Peter Robinson 2017-03-17 23:55:05 UTC
(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
$

Comment 6 Tom Stellard 2017-03-17 23:56:07 UTC
Which processor are you testing on?

Comment 7 Peter Robinson 2017-03-17 23:59:38 UTC
(In reply to Tom Stellard from comment #6)
> Which processor are you testing on?

ARMv7 Cortex-A7

Comment 8 Peter Robinson 2017-03-18 00:02:34 UTC
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

Comment 9 Peter Robinson 2017-03-18 00:06:46 UTC
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....

Comment 10 Peter Robinson 2017-03-18 00:08:21 UTC
(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.

Comment 11 Tom Stellard 2017-03-18 00:09:39 UTC
What should the triple be?

Comment 12 Tom Stellard 2017-03-18 00:10:36 UTC
Also, can you post /proc/cpuinfo for the systems where it doesn't work.

Comment 13 Peter Robinson 2017-03-18 00:12:06 UTC
(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

Comment 14 Peter Robinson 2017-03-18 00:15:24 UTC
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

Comment 15 Peter Robinson 2017-03-18 00:20:47 UTC
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

Comment 16 Peter Robinson 2017-03-18 00:30:11 UTC
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

Comment 17 Josh Stone 2017-03-18 00:32:40 UTC
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

Comment 18 Josh Stone 2017-03-18 00:35:00 UTC
(I'm referring only to the unknown vendor in the triple, not the host cpu.)

Comment 19 Tom Stellard 2017-03-18 00:57:46 UTC
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.

Comment 20 Peter Robinson 2017-03-18 01:03:14 UTC
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

Comment 21 Fedora Admin XMLRPC Client 2017-05-04 13:56:59 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 22 Tom Stellard 2017-08-25 03:00:10 UTC
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?

Comment 23 Peter Robinson 2017-08-25 08:49:55 UTC
> 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


Note You need to log in before you can comment on or make changes to this bug.