From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id E31E33857031 for ; Mon, 13 Jul 2020 08:57:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E31E33857031 Received: by mail-ej1-x631.google.com with SMTP id f12so15701540eja.9 for ; Mon, 13 Jul 2020 01:57:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CFd3pOHs7Q2sJalVPPwONOKZyckstEwofnQ/idxkFrM=; b=jtsmLx4+bDH9cdnKqF4g/dJy69bae4H3WnnI1is8qeTiccsxhdbNeTmyXGu8qzUz9i as1HMUrUFZIxEWuZ7ipLBONYdTNlYC6l20z0bK82+/4L2ReUOgJ8p4np6KfFnfvQXesA 29HfWJoZKiJTg6BeR1Bt1PFKVjVGFS4IZi7CY/+EFizFETNRI6bAw7NIr9e88q0gKj28 aHF7bIpiubxvY2TGqhEQD/oxQfHepiUcE8u9ioGOrG5yIdNYF+zoJnofNzMjzRVsvkZW 99P02nWsF8z9iGIIaJU6E12PtS8g3zUjGVFCWkU3eVvdH+C1xJR+XCJKyMzXwRiJLoDU dGAw== X-Gm-Message-State: AOAM531UJm3xSzF6+8UbBdf+KwEjd7QkWhTd04OXxUClV4jMf4ApgxC3 IQuqWoNcdFLGVpdX7ef1lwjGSkmkodenpTU3yQU= X-Google-Smtp-Source: ABdhPJy7E59ro+HJJ4khByf4kBtpPgz2h4EqoT20/tZYWL4cwGJg26KCcdAoSk+CTnKUBSGk0n6csNRxCcz0IP7Yf5Y= X-Received: by 2002:a17:906:2e50:: with SMTP id r16mr6935820eji.371.1594630657990; Mon, 13 Jul 2020 01:57:37 -0700 (PDT) MIME-Version: 1.0 References: <87365zz3a6.fsf@oldenburg2.str.redhat.com> <87pn8zuaky.fsf@oldenburg2.str.redhat.com> In-Reply-To: <87pn8zuaky.fsf@oldenburg2.str.redhat.com> From: Richard Biener Date: Mon, 13 Jul 2020 10:57:26 +0200 Message-ID: Subject: Re: New x86-64 micro-architecture levels To: Florian Weimer Cc: "H.J. Lu" , GCC Development , GNU C Library , Tom Stellard , llvm-dev@lists.llvm.org, "Mallappa, Premachandra" , x86-64-abi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 08:57:40 -0000 On Mon, Jul 13, 2020 at 9:40 AM Florian Weimer wrote: > > * Richard Biener: > > >> Looks good. I like it. > > > > Likewise. Btw, did you check that VIA family chips slot into Level A > > at least? > > Those seem to lack SSE4.2, so they land in the baseline. > > > Where do AMD bdverN slot in? > > bdver1 to bdver3 (as defined by GCC) should land in Level B (so Level A > if that is dropped). bdver4 and znver1 (and later) should land in > Level C. > > >> My only concerns are > >> > >> 1. Names like =E2=80=9Cx86-100=E2=80=9D, =E2=80=9Cx86-101=E2=80=9D, wh= at features do they support? > > > > Indeed I didn't get the -100, -101 part. On the GCC side I'd have > > suggested -march=3Dgeneric-{A,B,C,D} implying the respective > > -mtune. > > With literal A, B, C, D, or are they just placeholders? If not literal > levels, then what we should use there? > > I like the simplicity of numbers. I used letters in the proposal to > avoid confusion if we alter the proposal by dropping or levels, shifting > the meaning of those that come later. I expect to switch back to > numbers again for the final version. They are indeed placeholders though I somehow prefer letters to numbers. But this is really bike-shedding territory. Good documentation on the tools side will be more imporant as well as consistent spelling between tools sets, possibly driven by a good choice from within the psABI document. Richard.