Hi Kyrill, In AMD Seattle board, I see that CPU implementer is 0x41 and CPU part is 0xd07. CPU variant is 1 but you don’t do anything with that. It matches with cortex-a57 and its features.
I will try a bootstrap test as well. Regards, Venkat. -----Original Message----- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Kyrill Tkachov Sent: Monday, April 20, 2015 9:18 PM To: GCC Patches Cc: Marcus Shawcroft; Richard Earnshaw; James Greenhalgh; Evandro Menezes; Andrew Pinski; James Greenhalgh Subject: [PATCH][AArch64] Implement -m{cpu,tune,arch}=native using only /proc/cpuinfo 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. 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.
