public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Dongsheng Song <dongsheng.song@gmail.com>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	 "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
	Tom Stellard <tstellar@redhat.com>,
	 "llvm-dev@lists.llvm.org" <llvm-dev@lists.llvm.org>,
	 "Mallappa, Premachandra" <Premachandra.Mallappa@amd.com>,
	 "x86-64-abi@googlegroups.com" <x86-64-abi@googlegroups.com>
Subject: Re: New x86-64 micro-architecture levels
Date: Wed, 22 Jul 2020 11:26:42 +0200	[thread overview]
Message-ID: <CAFiYyc2hu=PJZGiS4oMH80xsg2-Ekvo6LSz5-sH2JC8ko=vy4Q@mail.gmail.com> (raw)
In-Reply-To: <87d04oj5vj.fsf@oldenburg2.str.redhat.com>

On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
>
> * Dongsheng Song:
>
> > I fully agree these names (100/101, A/B/C/D) are not very intuitive, I
> > recommend using isa tags by year (e.g. x64_2010, x64_2014) like the
> > python's platform tags (e.g. manylinux2010, manylinux2014).
>
> I started out with a year number, but that was before the was Level A.
> Too many new CPUs only fall under level A unfortunately because they do
> not even have AVX.  This even applies to some new server CPU designs
> released this year.
>
> I'm concerned that putting a year into the level name suggests that
> everything main-stream released after that year supports that level, and
> that's not true.  I think for manylinux, it's different, and it actually
> works out there.  No one is building a new GNU/Linux distribution that
> is based on glibc 2.12 today, for example.  But not so much for x86
> CPUs.
>
> If you think my worry is unfounded, then a year-based approach sounds
> compelling.

I think the main question is whether those levels are supposed to be
an implementation detail hidden from most software developer or
if people are expected to make concious decisions between
-march=x86-100 and -march=x86-101.  Implementation detail
for system integrators, that is.

If it's not merely an implementation detail then names without
any chance of providing false hints (x86-2014 - oh, it will
run fine on the CPU I bought in 2015; or, x86-avx2 - ah, of
course I want avx2) is better.  But this also means this feature
should come with extensive documentation on how it is
supposed to be used.  For example we might suggest ISVs
provide binaries for all architecture levels or use IFUNCs
or other runtime CPU selection capabilities.  It's also required
to provide a (extensive?) list of SKUs that fall into the respective
categories (probably up to CPU vendors to amend those).
Since this is a feature crossing multiple projects - at least
glibc and GCC - sharing the source of said documentation
would be important.

So for the bike-shedding I indeed think x86-10{0,1,2,3}
or x86-{A,B,C,..}, eventually duplicating as x86_64- as
suggested by Jan is better than x86-2014 or x86-avx2.

Richard.

> Thanks,
> Florian
>

  reply	other threads:[~2020-07-22  9:26 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-10 17:30 Florian Weimer
2020-07-10 19:14 ` Joseph Myers
2020-07-13  7:55   ` Florian Weimer
2020-07-10 21:42 ` H.J. Lu
2020-07-13  6:23   ` Richard Biener
2020-07-13  7:40     ` Florian Weimer
2020-07-13  7:47       ` Jan Beulich
2020-07-13 13:31         ` H.J. Lu
2020-07-13 13:53           ` Jakub Jelinek
2020-07-13  8:57       ` Richard Biener
2020-07-13  6:49   ` Florian Weimer
2020-07-13 13:30     ` H.J. Lu
2020-07-11  7:40 ` Allan Sandfeld Jensen
2020-07-13  6:58   ` Florian Weimer
2020-07-15 14:38 ` Mark Wielaard
2020-07-15 14:45   ` H.J. Lu
2020-07-15 14:56   ` Florian Weimer
2020-07-21 16:05 ` Mallappa, Premachandra
2020-07-21 18:04   ` Florian Weimer
2020-07-22  1:31     ` Dongsheng Song
2020-07-22  8:44       ` Florian Weimer
2020-07-22  9:26         ` Richard Biener [this message]
2020-07-22 10:16           ` Florian Weimer
2020-07-22 13:50             ` Richard Biener
2020-07-22 14:21               ` H.J. Lu
2020-07-31 13:06           ` Carlos O'Donell
2020-07-22  7:48     ` Jan Beulich
2020-07-22 10:34       ` Florian Weimer
2020-07-22 11:41         ` Jan Beulich
2020-07-31 13:20         ` Carlos O'Donell
2020-07-22 16:45     ` Mallappa, Premachandra
2020-07-23 12:44       ` Michael Matz
2020-07-23 13:21         ` H.J. Lu
2020-07-28 15:54       ` Florian Weimer

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='CAFiYyc2hu=PJZGiS4oMH80xsg2-Ekvo6LSz5-sH2JC8ko=vy4Q@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=Premachandra.Mallappa@amd.com \
    --cc=dongsheng.song@gmail.com \
    --cc=fweimer@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=libc-alpha@sourceware.org \
    --cc=llvm-dev@lists.llvm.org \
    --cc=tstellar@redhat.com \
    --cc=x86-64-abi@googlegroups.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).