public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Kumar, Venkataramanan" <Venkataramanan.Kumar@amd.com>
To: Kyrill Tkachov <kyrylo.tkachov@arm.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>,
	James Greenhalgh <james.greenhalgh@arm.com>
Subject: RE: [PATCH][AArch64] Implement -m{cpu,tune,arch}=native using only /proc/cpuinfo
Date: Tue, 21 Apr 2015 04:41:00 -0000	[thread overview]
Message-ID: <7794A52CE4D579448B959EED7DD0A4723DCE75F4@satlexdag06.amd.com> (raw)
In-Reply-To: <55351FA9.4020603@arm.com>

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-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.

  parent reply	other threads:[~2015-04-21  4:41 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 [this message]
2015-04-21  8:05   ` Kyrill Tkachov
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=7794A52CE4D579448B959EED7DD0A4723DCE75F4@satlexdag06.amd.com \
    --to=venkataramanan.kumar@amd.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=apinski@cavium.com \
    --cc=e.menezes@samsung.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=james.greenhalgh@arm.com \
    --cc=kyrylo.tkachov@arm.com \
    --cc=marcus.shawcroft@arm.com \
    /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).