On 7/22/20 6:34 AM, Florian Weimer wrote:
> * Jan Beulich:
>
>> On 21.07.2020 20:04, Florian Weimer wrote:
>>> * Premachandra Mallappa:
>>>
[AMD Public Use]
Hi Floarian,
> I'm including a proposal for the levels below. I use single
> letters for them, but I expect t
On 7/22/20 5:26 AM, Richard Biener via Libc-alpha wrote:
> 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.
Agreed. If we really want to be clear, call it a "level"
or something
* Premachandra Mallappa:
> [AMD Public Use]
>>> Also we would also like to have dynamic loader support for "zen" /
>>> "zen2" as a version of "Level D" and takes preference over Level D,
>>> which may have super-optimized libraries from AMD or other vendors.
>
>> *That* shouldn't be too hard to
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).
> >
> > Und
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-sse
[AMD Public Use]
> 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,
On Wed, Jul 22, 2020 at 6:50 AM Richard Biener via Libc-alpha
wrote:
>
> On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer wrote:
> >
> > * Richard Biener:
> >
> > > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc
> > > wrote:
> > >>
> > >> * Dongsheng Song:
> > >>
> > >> > I fully agree
On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer wrote:
>
> * Richard Biener:
>
> > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc
> > wrote:
> >>
> >> * Dongsheng Song:
> >>
> >> > I fully agree these names (100/101, A/B/C/D) are not very intuitive, I
> >> > recommend using isa tags by
On 22.07.2020 12:34, Florian Weimer wrote:
> The remaining issue is the - vs _ issue. I think GCC currently uses
> “x86-64” in places that are not part of identifiers or target triplets.
> Richard mentioned “x86_64-” as a potential choice. Would it be too
> awkward to have ”-march=x86_64-…”?
Per
* Jan Beulich:
> On 21.07.2020 20:04, Florian Weimer wrote:
>> * Premachandra Mallappa:
>>
>>> [AMD Public Use]
>>>
>>> Hi Floarian,
>>>
I'm including a proposal for the levels below. I use single letters for
them, but I expect that the concrete implementation of this proposal will
>
* Richard Biener:
> On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc
> 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. m
On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc 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).
* 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
On 21.07.2020 20:04, Florian Weimer wrote:
> * Premachandra Mallappa:
>
>> [AMD Public Use]
>>
>> Hi Floarian,
>>
>>> I'm including a proposal for the levels below. I use single letters for
>>> them, but I expect that the concrete implementation of this proposal will
>>> use
>>> names like “x8
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).
* Premachandra Mallappa:
> [AMD Public Use]
>
> Hi Floarian,
>
>> I'm including a proposal for the levels below. I use single letters for
>> them, but I expect that the concrete implementation of this proposal will
>> use
>> names like “x86-100”, “x86-101”, like in the glibc patch referenced a
[AMD Public Use]
Hi Floarian,
> I'm including a proposal for the levels below. I use single letters for
> them, but I expect that the concrete implementation of this proposal will use
> names like “x86-100”, “x86-101”, like in the glibc patch referenced above.
> (But we can discuss other app
* Mark Wielaard:
> One thing that wasn't clear to me from this proposal is how the glibc
> dynamic loader checks for the CPU feature flags. This is important for
> valgrind since it can communicate those through different means. cpuid
> interception, auxv AT_HWCAP/AT_HWCAP2 interception (but not A
On Wed, Jul 15, 2020 at 7:38 AM Mark Wielaard wrote:
>
> Hi Florian,
>
> I understand you want to discuss the x86_64 micro-architecture levels
> only in this thread, but it would be nice to have a similar discussion
> for other architectures.
>
> One thing that wasn't clear to me from this proposa
Hi Florian,
I understand you want to discuss the x86_64 micro-architecture levels
only in this thread, but it would be nice to have a similar discussion
for other architectures.
One thing that wasn't clear to me from this proposal is how the glibc
dynamic loader checks for the CPU feature flags.
On Mon, Jul 13, 2020 at 06:31:31AM -0700, H.J. Lu via Gcc wrote:
> > > H.J. has patches for ELF program properties. I think
> > > GNU_PROPERTY_X86_ISA_1_NEEDED would convey this information. This
> > > proposal and the glibc patches are independent of that.
> >
> > From (partly just halfway) rece
On Mon, Jul 13, 2020 at 12:48 AM Jan Beulich wrote:
>
> On 13.07.2020 09:40, Florian Weimer wrote:
> > * Richard Biener:
> >>> 2. I have a library with AVX2 and FMA, which directory should it go?
> >>
> >> Eventually GCC/gas can annotate objects with the lowest architecture
> >> level that is appl
On Sun, Jul 12, 2020 at 11:49 PM Florian Weimer wrote:
>
> * H. J. Lu:
>
> > Looks good. I like it.
>
> Thanks. What do you think about Level B? Should we keep it?
Please drop Level B.
> > My only concerns are
> >
> > 1. Names like “x86-100”, “x86-101”, what features do they support?
>
> I th
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?
>
>
* Joseph Myers:
> On Fri, 10 Jul 2020, Florian Weimer via Gcc wrote:
>
>> * Level A
>>
>> CMPXCHG16B, LAHF/SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
>>
>> This is one step above the K8 baseline and corresponds to a mainline CPU
>> model ca. 2008 to 2011. It is also implemented by recent-ish
>>
On 13.07.2020 09:40, Florian Weimer wrote:
> * Richard Biener:
>>> 2. I have a library with AVX2 and FMA, which directory should it go?
>>
>> Eventually GCC/gas can annotate objects with the lowest architecture
>> level that is applicable?
>
> H.J. has patches for ELF program properties. I think
* 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 t
* Allan Sandfeld Jensen:
> On Freitag, 10. Juli 2020 19:30:09 CEST Florian Weimer via Gcc wrote:
>> glibc (or an alternative loader implementation) would search for
>> libraries starting at level D, going back to level A, and finally the
>> baseline implementation in the default library location.
* H. J. Lu:
> Looks good. I like it.
Thanks. What do you think about Level B? Should we keep it?
> My only concerns are
>
> 1. Names like “x86-100”, “x86-101”, what features do they support?
I think we can add more diagnostic output to ld.so --help. My patch
does not show individual CPU fla
On Fri, Jul 10, 2020 at 11:45 PM H.J. Lu via Gcc wrote:
>
> On Fri, Jul 10, 2020 at 10:30 AM Florian Weimer wrote:
> >
> > Most Linux distributions still compile against the original x86-64
> > baseline that was based on the AMD K8 (minus the 3DNow! parts, for Intel
> > EM64T compatibility).
> >
On Freitag, 10. Juli 2020 19:30:09 CEST Florian Weimer via Gcc wrote:
> glibc (or an alternative loader implementation) would search for
> libraries starting at level D, going back to level A, and finally the
> baseline implementation in the default library location.
>
> I expect that some distrib
On Fri, Jul 10, 2020 at 10:30 AM Florian Weimer wrote:
>
> Most Linux distributions still compile against the original x86-64
> baseline that was based on the AMD K8 (minus the 3DNow! parts, for Intel
> EM64T compatibility).
>
> There has been an attempt to use the existing AT_PLATFORM-based loadi
On Fri, 10 Jul 2020, Florian Weimer via Gcc wrote:
> * Level A
>
> CMPXCHG16B, LAHF/SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
>
> This is one step above the K8 baseline and corresponds to a mainline CPU
> model ca. 2008 to 2011. It is also implemented by recent-ish
> generations of Intel Atom s
33 matches
Mail list logo
