From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) by sourceware.org (Postfix) with ESMTPS id 229D83857028 for ; Wed, 27 Jul 2022 16:44:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 229D83857028 Received: by mail-oo1-xc31.google.com with SMTP id j1-20020a4ab1c1000000b0043576bcb9b1so3305158ooo.10 for ; Wed, 27 Jul 2022 09:44:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:organization:in-reply-to :content-transfer-encoding; bh=uhluHZTLYT/dXKjd9UsJlc+HyyNPdG7Rdm9NOmnbv3I=; b=jT9cVlqYyXxcLmBYOy5t5+geQ2BlIKPGmJRK/uXMa8tEbMnau/2Y9Eqty09I+ikPRO YwreNu5Zn+zMPyfx0w/NC2Ut/mOhMuW+SP9dvqvLgwLjhKCytWTZY+21KxUTJfSTQpqR tDauJ3Yz1WJ/yiH+AXy8Q5Qfa9Dd8Ue9tduwDsfH/3YubC2Af0ijQgI37qKVzFI7HONB GUzPUkQEd3eMUe0iDoUGdgEkLQub0MVlyAF0NSSsYtIpR0fV8R21CCcLRFp/iQdF4ZNa 8wcxMjqnP/XE7Ts53tzV5ox7qtsqJxzmD03LsyIYqR5jlJcVl7wt8QGUv7VNhdsBIFtU DHXg== X-Gm-Message-State: AJIora+l8IL6F897hjTtKRJ5zL0kh+NsutSPiq0FCMojVE0ZdcWPPWl8 hpOIfluoROMdvwbikJqCzIW8mtMWlmhAhQ== X-Google-Smtp-Source: AGRyM1teVd8wtGMJOzlHbEjCB2lxjzJKLgbvgEjGzAvWw/Klpw5v7vqlqu92rVe1eiTG08qMQobl1g== X-Received: by 2002:a4a:bd02:0:b0:435:e2dc:5fe9 with SMTP id n2-20020a4abd02000000b00435e2dc5fe9mr6423239oop.28.1658940246202; Wed, 27 Jul 2022 09:44:06 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:8ded:8925:49f1:c550:ee7d? ([2804:431:c7cb:8ded:8925:49f1:c550:ee7d]) by smtp.gmail.com with ESMTPSA id s30-20020a056870611e00b0010d04a20030sm9057841oae.36.2022.07.27.09.44.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Jul 2022 09:44:05 -0700 (PDT) Message-ID: Date: Wed, 27 Jul 2022 13:44:04 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.0.3 Subject: Re: [PATCH v2] NEWS: Add entry for x86-64 ISA level build Content-Language: en-US To: libc-alpha@sourceware.org References: <20220727065841.2140573-1-goldstein.w.n@gmail.com> <20220727121023.2146666-1-goldstein.w.n@gmail.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Wed, 27 Jul 2022 16:44:09 -0000 On 27/07/22 13:22, Noah Goldstein via Libc-alpha wrote: > On Thu, Jul 28, 2022 at 12:12 AM Joseph Myers wrote: >> >> On Wed, 27 Jul 2022, Noah Goldstein via Libc-alpha wrote: >> >>> +* Support building x86-64 with multiple ISA levels has been added. >>> + Higher ISA levels will use better optimized functions in the dynamic >>> + loader and non-multiarch build as well as reduce the size of libc.so. >> >> I don't think "with multiple ISA levels" is very meaningful to users. >> How is "with multiple ISA levels" different from the multi-arch feature >> that's been present for many years - I think it could easily be read as a >> description of that longstanding existing feature? You need a description >> that makes clear to users who aren't following glibc development what the >> actual new feature is (i.e. that if you build with a compiler that >> defaults to a newer ISA level such as -march=x86-64-v2, the resulting libc >> will use corresponding optimized implementations and omit the versions >> only relevant on older processors, if I'm understanding the feature >> correctly). > > That's fair. > > Not really sure this needs a NEWS entry at the end of the day. It's not really > directly visible. The only meaningful change is that there won't be any > legacy sse code so potentially (with great care) a user could entirely > omit `vzeroupper`. > > Adhemerval do you think this needs an entry or is it too behind the scenes? I had the impression that reorganization would allow an user visible optimization (due the code ifunc selection change), but in the end I agree that is should be transparent to users. I don't have a strong opinion here, maybe it is would be better to omit.