Update ARM feature and CPU detection (supersedes #36464)

[IanButterworth]

I messed up #36464 with an accidental blank force push, so that PR can't be reopened. This is the replacement

Updates ARM feature and CPU detection

cc. @yuyichao

[IanButterworth]

I applied these changes on-top of #35318 (without rebase) and still get generic for this graviton2 machine:

   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.0-DEV.545 (2020-03-31)
 _/ |\__'_|_|_|\__'_|  |  vc/upgrade_llvm_10/8ae92cc5f0* (fork: 1 commits, 91 days)
|__/                   |

julia> versioninfo()
Julia Version 1.5.0-DEV.545
Commit 8ae92cc5f0* (2020-03-31 01:16 UTC)
Platform Info:
  OS: Linux (aarch64-linux-gnu)
  CPU: unknown
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-10.0.0 (ORCJIT, generic)
Environment:
  JULIA_NUM_THREADS = 16

But there are more features for:

julia> ccall(:jl_dump_host_cpu, Cvoid, ())
CPU: generic
Features: aes, sha2, crc, lse, fullfp16, rdm, rcpc, ccpp, dotprod, ssbs

1.4.2 gives:

julia> ccall(:jl_dump_host_cpu, Cvoid, ())
CPU: generic
Features: crypto, crc, lse, fullfp16, rdm, rcpc, dcpop

[yuyichao]

.... There was a bug in the error checking. I guess I never had any hardware to test where LLVM is not able to detect... (cortex-a57 only basically....)

The fix is the second commit. You should be able to just cherry pick that for testing (assuming it compiles....)

[IanButterworth]

Great, now working!

julia> versioninfo()
Julia Version 1.5.0-DEV.545
Commit 8ae92cc5f0* (2020-03-31 01:16 UTC)
Platform Info:
  OS: Linux (aarch64-linux-gnu)
  CPU: unknown
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-10.0.0 (ORCJIT, neoverse-n1)
Environment:
  JULIA_NUM_THREADS = 16

julia> ccall(:jl_dump_host_cpu, Cvoid, ())
CPU: neoverse-n1
Features: aes, sha2, crc, lse, fullfp16, rdm, rcpc, ccpp, dotprod, ssbs, v8_1a, v8_2a

Although I did hit a non-fatal bug when I first generated a function after build (after running above):

ERROR: error: failed to compute relocation: R_AARCH64_PREL64, Invalid data was encountered while parsing the file

[yuyichao]

This PR should change nothing regarding relocation, especially if you are not manually specifying any target during compilation.
It is possible though that the LLVM linker or something is not able to handle some features or code patterns caused either by the processor name or the features.

Running it in debugger might give you at least some idea when/where/on which function/code it happens. You can also try specifying the cpu target -C when you start julia to disable features or set a different CPU name, e.g. -C "native,-ssbs" or -C "cortex-a76". If you can identify the feature/CPU that's problematic we can disable it by raising the LLVM version requirement.

[vchuravy]

Those relocation warnings look like #35460

[IanButterworth]

Indeed:

julia> error()
ERROR: error: failed to compute relocation: R_AARCH64_PREL64, Invalid data was encountered while parsing the file
error: failed to compute relocation: R_AARCH64_PREL64, Invalid data was encountered while parsing the file
error: failed to compute relocation: R_AARCH64_PREL64, Invalid data was encountered while parsing the file

[vchuravy]

And you are indeed on LLVM10

[IanButterworth]

@yuyichao what would count as success here? Should we try to run julia tests on some of the added aarch64 CPU’s? Is now the time to do that?

[yuyichao]

The PR is already done and is just waiting to see if anyone else have any comments before merging. (though I did make another update due to recent LLVM 11 addition and that I managed to find the TRM for cortex-a78 and cortex-x1.)

It's impossible to test on all CPUs and I don't think that's required for merging. If you do have non cortex-a57, carmel or neoverse-n1 to test that would be nice. And since the commit was in a "finished" state when I first pushed it the test can be done at any time.

[IanButterworth]

I noticed that #36502 was backported to 1.5-rc2, so wondered if this could be?

cc. @KristofferC

[yuyichao]

I mentioned backporting in that one because of the one bug fix in it. But if the whole pr is considered backportable then this one should be the same. The second commit here is also k8nd of a bug fix.

[IanButterworth]

I think that's logical, and agree that the 2nd commit is a bug fix. @KristofferC would a backport be acceptable?