public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kyrill Tkachov <kyrylo.tkachov@arm.com>
To: "Kumar, Venkataramanan" <Venkataramanan.Kumar@amd.com>,
	 GCC Patches <gcc-patches@gcc.gnu.org>
Cc: Marcus Shawcroft <Marcus.Shawcroft@arm.com>,
	 Richard Earnshaw <Richard.Earnshaw@arm.com>,
	James Greenhalgh <James.Greenhalgh@arm.com>,
	 Evandro Menezes <e.menezes@samsung.com>,
	Andrew Pinski <apinski@cavium.com>
Subject: Re: [PATCH][AArch64] Implement -m{cpu,tune,arch}=native using only /proc/cpuinfo
Date: Tue, 21 Apr 2015 08:05:00 -0000	[thread overview]
Message-ID: <553604CF.7050004@arm.com> (raw)
In-Reply-To: <7794A52CE4D579448B959EED7DD0A4723DCE75F4@satlexdag06.amd.com>


On 21/04/15 05:41, Kumar, Venkataramanan wrote:
> 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.

Thanks, that's a Cortex-A57.

>
> I will try a bootstrap test as well.

Awesome.
I'd like to have a --with-{arch,tune,cpu}=native configure option at some point in the future
but I'm not sure at the moment how that would be done without some refactoring.

Kyrill

>
> Regards,
> Venkat.
>   
>
> -----Original Message-----
> From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-owner@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.tkachov@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.

  reply	other threads:[~2015-04-21  8:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-20 15:48 Kyrill Tkachov
2015-04-20 19:36 ` Andrew Pinski
2015-04-21  4:41 ` Kumar, Venkataramanan
2015-04-21  8:05   ` Kyrill Tkachov [this message]
2015-04-21 20:11 ` Evandro Menezes
2015-04-22 11:46 ` Kyrill Tkachov
2015-04-22 15:08   ` Kyrill Tkachov
2015-04-24  7:08     ` Kumar, Venkataramanan
2015-04-24  8:39     ` Marcus Shawcroft
2015-04-24 14:55       ` Kyrill Tkachov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=553604CF.7050004@arm.com \
    --to=kyrylo.tkachov@arm.com \
    --cc=James.Greenhalgh@arm.com \
    --cc=Marcus.Shawcroft@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=Venkataramanan.Kumar@amd.com \
    --cc=apinski@cavium.com \
    --cc=e.menezes@samsung.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).