On Mon, Apr 20, 2015 at 8:47 AM, Kyrill Tkachov <kyrylo.tkac...@arm.com> wrote:
> Hi all,
>
> This is an attempt to add native CPU detection to AArch64 GNU/Linux targets.
> Similar to other ports we use SPEC rewriting to rewrite
> -m{cpu,tune,arch}=native
> options into the appropriate CPU/architecture and the architecture extension
> options
> when appropriate (i.e. +crypto/+crc etc).
>
> For CPU/architecture detection it gets a bit involved, especially when
> running on a
> big.LITTLE system. My proposed approach is to look at /proc/cpuinfo/ and
> search for the
> implementer id and part number fields that uniquely identify each core
> (appropriate identifying
> information is added to aarch64-cores.def). If we find two types of core we
> have a big.LITTLE
> system, so search through the core definitions extracted from
> aarch64-cores.def to find if we
> support such a combination (currently only cortex-a57.cortex-a53 and
> cortex-a72.cortex-a53)
> and make sure that the implementer id field matches up.
>
> I tested this on a 4xCortex-A53 + 2xCortex-A57 big.LITTLE Ubuntu GNU/Linux
> system.
> There are two formats for /proc/cpuinfo/ that I'm aware of. The first (old)
> one has the format:
> --------------------------------------
> processor : 0
> processor : 1
> processor : 2
> processor : 3
> processor : 4
> processor : 5
> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
> CPU implementer : 0x41
> CPU architecture: AArch64
> CPU variant : 0x0
> CPU part : 0xd03
> --------------------------------------
>
> In this format it lists the 6 cores but the CPU part it reports is only the
> one for the core
> from which /proc/cpuinfo was read from (!), in this case one of the
> Cortex-A53 cores.
> This means we detect a different CPU depending on which
> core GCC was invoked on. Not ideal really, but there's no more information
> that we can extract.
> Given the /proc/cpuinfo above, this patch will rewrite -mcpu=native into
> -mcpu=cortex-a53+fp+simd+crypto+crc
>
> The newer /proc/cpuinfo format proposed at
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=44b82b7700d05a52cd983799d3ecde1a976b3bed
> looks like this:
>
> --------------------------------------------------------------
> processor : 0
> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
> CPU implementer : 0x41
> CPU architecture: 8
> CPU variant : 0x0
> CPU part : 0xd03
> CPU revision : 0
>
> processor : 1
> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
> CPU implementer : 0x41
> CPU architecture: 8
> CPU variant : 0x0
> CPU part : 0xd03
> CPU revision : 0
>
> processor : 2
> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
> CPU implementer : 0x41
> CPU architecture: 8
> CPU variant : 0x0
> CPU part : 0xd03
> CPU revision : 0
>
> processor : 3
> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
> CPU implementer : 0x41
> CPU architecture: 8
> CPU variant : 0x0
> CPU part : 0xd03
> CPU revision : 0
>
> processor : 4
> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
> CPU implementer : 0x41
> CPU architecture: 8
> CPU variant : 0x0
> CPU part : 0xd07
> CPU revision : 0
>
> processor : 5
> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
> CPU implementer : 0x41
> CPU architecture: 8
> CPU variant : 0x0
> CPU part : 0xd07
> CPU revision : 0
> --------------------------------------------------------------
>
> The Features field is used to detect the architectural features that we map
> to GCC option extensions
> i.e. +fp,+crypto,+simd,+crc etc.
>
> Similarly, -march=native would be rewritten into
> -march=armv8-a+fp+simd+crypto+crc
> while -mtune=native into -march=cortex-a57.cortex-a53 (the arch extension
> options are not valid
> for -mtune).
>
> If it detects more than one implementer ID or the implementer IDs not
> matching up somewhere
> or some other weirdness /proc/cpuinfo or fails to recognise the CPU it will
> bail out and ignore
> the option entirely (similarly to other ports).
>
> The patch works fine with both /proc/cpuinfo formats although, as mentioned
> above, it will not be
> able to detect the big.LITTLE combination from the first format.
>
> I've filled in the implementer ID and part numbers for the Cortex-A57,
> Cortex-A53, Cortex-A72, X-Gene 1 cores,
> but I don't have that info for thunderx or exynosm1. Could someone from
> Cavium and Samsung help me out
> here? At present this patch has some false dummy values that I'd like to
> fill out before committing this.
Here is the /proc/cpuinfo for Pass 1.0 of ThunderX1:
Features : fp asimd aes pmull sha1 sha2 crc32
CPU implementer : 0x43
CPU architecture: AArch64
CPU variant : 0x0
CPU part : 0x0a1
CPU revision : 0
Thanks,
Andrew Pinski
>
> I've bootstrapped this on the system mentioned above with -mcpu=native in
> the BOOT_CFLAGS and regtested as well.
> For the bootstrap I've used the 2nd /proc/cpuinfo format.
>
> I've also tested it on AArch64 hardware from ARM Ltd. and the ecosystem.
>
> If using the first format the bootstrap fails the comparison because,
> depending on the OS scheduling, some files
> are compiled with Cortex-A57 tuning and some with Cortex-A53 tuning and this
> is practically non-deterministic
> across stage2 and stage3!
>
> What do people think of this approach?
>
> 2014-04-20 Kyrylo Tkachov <kyrylo.tkac...@arm.com>
>
> * config.host (case ${host}): Add aarch64*-*-linux case.
> * config/aarch64/aarch64-cores.def: Add IMPLEMENTER_ID and PART_NUMBER
> fields to all the cores.
> * config/aarch64/aarch64-elf.h (DRIVER_SELF_SPECS): Add
> MCPU_MTUNE_NATIVE_SPECS.
> * config/aarch64/aarch64-option-extensions.def: Add FEAT_STRING field to
> all
> extensions.
> * config/aarch64/aarch64-opts.h: Adjust definition of AARCH64_CORE.
> * config/aarch64/aarch64.c: Adjust definition of AARCH64_CORE.
> Adjust definition of AARCH64_OPT_EXTENSION.
> * config/aarch64/aarch64.h: Adjust definition of AARCH64_CORE.
> (MCPU_MTUNE_NATIVE_SPECS): Define.
> * config/aarch64/driver-aarch64.c: New file.
> * config/aarch64/x-arch64: New file.
> * doc/invoke.texi (AArch64 Options): Document native value for -mcpu,
> -mtune and -march.
