From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) by sourceware.org (Postfix) with ESMTPS id D7EEA3857C5A for ; Thu, 23 Jul 2020 13:22:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D7EEA3857C5A Received: by mail-il1-x144.google.com with SMTP id j9so904706ilc.11 for ; Thu, 23 Jul 2020 06:22:25 -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; bh=yaxy7t/RXwt6WERT3XL/sxt44YogrbkgUZwVvjJjyHM=; b=gM/9o7/YHOGazW3DQ5PfiduNwJa809kLc/9hNH6ejdfP/Vr3Jm2OxXYjh6OZnPi0Lg caH6BNg+mCwPpuWCXtTK0qfMHwURIRqDXgb4r5L69SRkam8Cj+sGkPqPTuN6x5mtip3l kvqveUWwi73Ejfw2AIjDtpaB+qeC1fSzYS7RWkF0yd+pf5u9IZt1htNNsSa8i4eOHOEB 8oV20hT25q+7jteHshvf+zif/GPW0jfjFS9YIc+XZtRljCk83QtYkJ4aT0zVjZulKOag i01+8d4LymGXG3gzI3/HTFo2Y+I6C+yNvdD75VsGA6fhSoSRI5s7ccEDRfNujC7SoQpN ONTg== X-Gm-Message-State: AOAM531PEyVyYqdlTx4WQ93TWDkkav5IL4eSk3gbcyfndctFrYft/Wcg ZYCHfG2N9nAHdHtaubnjE4/h6UTh/192cGQ9DLM= X-Google-Smtp-Source: ABdhPJzexieXkfOlzDIXzZJ3gG7Uv/BFmUyWOFGKF+fTAtmwEVnBkTD6reyyvpVtChrnEE3Y/4ylAnE7Ln55pMZWhy4= X-Received: by 2002:a92:cf42:: with SMTP id c2mr5198628ilr.13.1595510545186; Thu, 23 Jul 2020 06:22:25 -0700 (PDT) MIME-Version: 1.0 References: <87365zz3a6.fsf@oldenburg2.str.redhat.com> <87imegn3s0.fsf@oldenburg2.str.redhat.com> In-Reply-To: From: "H.J. Lu" Date: Thu, 23 Jul 2020 06:21:48 -0700 Message-ID: Subject: Re: New x86-64 micro-architecture levels To: Michael Matz Cc: "Mallappa, Premachandra" , Florian Weimer , "libc-alpha@sourceware.org" , "gcc@gcc.gnu.org" , "llvm-dev@lists.llvm.org" , "x86-64-abi@googlegroups.com" , Tom Stellard , Jeff Law Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.5 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: Thu, 23 Jul 2020 13:22:27 -0000 On Thu, Jul 23, 2020 at 5:44 AM Michael Matz wrote: > > Hello, > > On Wed, 22 Jul 2020, Mallappa, Premachandra wrote: > > > > That's deliberate, so that we can use the same x86-* names for 32-bit library selection (once we define matching micro-architecture levels there). > > > > Understood. > > > > > If numbers are out, what should we use instead? > > > x86-sse4, x86-avx2, x86-avx512? Would that work? > > > > Yes please, I think we have to choose somewhere, above would be more > > descriptive > > And IMHO that's exactly the problem. These names should _not_ be > descriptive, because any description invokes a wrong feeling of precision. > E.g. what Florian already mentioned: sse4 - does it imply 4.1 and 4.2, or > avx512: what of F, CD, ER, PF, VL, DQ, BW, IFMA, VBMI, 4VNNIW, 4FMAPS, > VPOPCNTDQ, VNNI, VBMI2, BITALG, VP2INTERSECT, GFNI, VPCLMULQDQ, VAES does > that one imply (rhethorical question, list shown just to make sillyness > explicit). > > Regarding precision: I think we should rule out any mathematically correct > scheme, e.g. one in which every ISA subset gets an index and the directory > name contains a hexnumber constructed by bits with the corresponding index > being one or zero, depending on if the ISA subset is required or not: I > think we're currently at about 40 ISA subsets, and hence would end up in > names like x86-32001afff and x86-22001afef (the latter missing two subset > compared to the former). > > No, IMHO the non-vendor names should be non-descript, and either be > numbers or characters, of which I would vote for characters, i.e. A, B, C. > Obviously, as already mentioned here, the mapping of level to feature set > needs to be described in documentation somewhere, and should be maintained > by either glibc, glibc/gcc/llvm or psABI people. > > I don't have many suggestions about vendor names, be them ISA-subset > market names, or core names or company names. I will just note that using > such names has lead to an explosion of number of names without very good > separation between them. As long as we're only talking about -march= > cmdline flags that may have been okay, if silly, but under this proposal > every such name is potentially a subdirectory containing many shared > libraries, and one that potentially needs to be searched at every library > looking in the dynamic linker; so it's prudent to limit the size of this > name set as well. > > As for which subsets should or shouldn't be required in which level: I > think the current suggestions all sound good, ultimately it's always going > to be some compromise. > We can have x86-64, x86-64-v1, x86-64-v2, ...... These pseudo names should be clearly documented. -- H.J.