[PATCH v1] NEWS: Add entry for x86-64 ISA level build

[PATCH v1] NEWS: Add entry for x86-64 ISA level build

[Noah Goldstein]

---
 NEWS | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/NEWS b/NEWS
index 5827b206d9..4264a4cfc6 100644
--- a/NEWS
+++ b/NEWS
@@ -72,6 +72,10 @@ Major new features:
 
   The LoongArch ABI is 64-bit little-endian.
 
+* Support building x86-64 with multiple ISA levels.  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.
+
 Deprecated and removed features, and other changes affecting compatibility:
 
 * Support for prelink will be removed in the next release; this includes
-- 
2.34.1

Re: [PATCH v1] NEWS: Add entry for x86-64 ISA level build

[Adhemerval Zanella Netto]

On 27/07/22 03:58, Noah Goldstein via Libc-alpha wrote:
> ---
>  NEWS | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/NEWS b/NEWS
> index 5827b206d9..4264a4cfc6 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -72,6 +72,10 @@ Major new features:
>  
>    The LoongArch ABI is 64-bit little-endian.
>  
> +* Support building x86-64 with multiple ISA levels.  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.

The initial sentence sounds terse, maybe "Support for building x86-64 with 
multiple ISA levels has been added".

> +
>  Deprecated and removed features, and other changes affecting compatibility:
>  
>  * Support for prelink will be removed in the next release; this includes

Re: [PATCH v1] NEWS: Add entry for x86-64 ISA level build

[Noah Goldstein]

On Wed, Jul 27, 2022 at 7:18 PM Adhemerval Zanella Netto via
Libc-alpha <libc-alpha@sourceware.org> wrote:
>
>
>
> On 27/07/22 03:58, Noah Goldstein via Libc-alpha wrote:
> > ---
> >  NEWS | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/NEWS b/NEWS
> > index 5827b206d9..4264a4cfc6 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -72,6 +72,10 @@ Major new features:
> >
> >    The LoongArch ABI is 64-bit little-endian.
> >
> > +* Support building x86-64 with multiple ISA levels.  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.
>
> The initial sentence sounds terse, maybe "Support for building x86-64 with
> multiple ISA levels has been added".
>

Sure. Done in V2.
> > +
> >  Deprecated and removed features, and other changes affecting compatibility:
> >
> >  * Support for prelink will be removed in the next release; this includes'
>

[PATCH v2] NEWS: Add entry for x86-64 ISA level build

[Noah Goldstein]

---
 NEWS | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/NEWS b/NEWS
index 5827b206d9..968187b3e8 100644
--- a/NEWS
+++ b/NEWS
@@ -72,6 +72,10 @@ Major new features:
 
   The LoongArch ABI is 64-bit little-endian.
 
+* 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.
+
 Deprecated and removed features, and other changes affecting compatibility:
 
 * Support for prelink will be removed in the next release; this includes
-- 
2.34.1

Re: [PATCH v2] NEWS: Add entry for x86-64 ISA level build

[Adhemerval Zanella Netto]

On 27/07/22 09:10, Noah Goldstein via Libc-alpha wrote:
> ---
>  NEWS | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/NEWS b/NEWS
> index 5827b206d9..968187b3e8 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -72,6 +72,10 @@ Major new features:
>  
>    The LoongArch ABI is 64-bit little-endian.
>  
> +* 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.
> +
>  Deprecated and removed features, and other changes affecting compatibility:
>  
>  * Support for prelink will be removed in the next release; this includes

LGTM, thanks.

It is ok for 2.36.

Re: [PATCH v2] NEWS: Add entry for x86-64 ISA level build

[Joseph Myers]

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

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH v2] NEWS: Add entry for x86-64 ISA level build

[Noah Goldstein]

On Thu, Jul 28, 2022 at 12:12 AM Joseph Myers <joseph@codesourcery.com> 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?

>
> --
> Joseph S. Myers
> joseph@codesourcery.com

Re: [PATCH v2] NEWS: Add entry for x86-64 ISA level build

[Adhemerval Zanella Netto]

On 27/07/22 13:22, Noah Goldstein via Libc-alpha wrote:
> On Thu, Jul 28, 2022 at 12:12 AM Joseph Myers <joseph@codesourcery.com> 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.