This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: munroesj at linux dot vnet dot ibm dot com
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, libc-alpha at sourceware dot org
- Date: Thu, 9 Jul 2015 12:34:56 +0200
- Subject: Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB
- Authentication-results: sourceware.org; auth=none
- References: <5591239A dot 9030907 at twiddle dot net> <1435603025 dot 5485 dot 23 dot camel at oc7878010663> <20150629211831 dot GA23965 at domone> <5591BD23 dot 6090501 at linaro dot org> <20150630031409 dot GA28953 at domone> <5592A310 dot 9010902 at linaro dot org> <20150630211515 dot GA26880 at domone> <55930E26 dot 3050203 at linaro dot org> <20150701115535 dot GA3025 at domone> <1436284056 dot 12188 dot 32 dot camel at oc7878010663>
On Tue, Jul 07, 2015 at 10:47:36AM -0500, Steven Munroe wrote:
> On Wed, 2015-07-01 at 13:55 +0200, OndÅej BÃlka wrote:
> > On Tue, Jun 30, 2015 at 06:46:14PM -0300, Adhemerval Zanella wrote:
> >> >>> I am telling all time that there are better alternatives where this
> > > >>> doesn't matter.
> > > >>>
> > > >>> One example would be write gcc pass that runs after early inlining to
> > > >>> find all functions containing __builtin_cpu_supports, cloning them to
> > > >>> replace it by constant and adding ifunc to automatically select variant.
> > > >>
> > > >> Using internal PLT calls to such mechanism is really not the way to handle
> > > >> performance for powerpc.
> > > >>
> > > > No you are wrong again. I wrote to introduce ifunc after inlining. You
> > > > do inlining to eliminate call overhead. So after inlining effect of
> > > > adding plt call is minimal, otherwise gcc should inline that to improve
> > > > performance in first place.
> > >
> > > It is the case if you have the function definition, which might not be
> > > true. But this is not the case since the code could be in a shared
> > > library.
> > >
> > Seriously? If its function from shared library then it should use ifunc
> > and not force every caller to keep hwcap selection in sync with library,
> > and you need plt indirection anyway.
> >
> if you believe so strongly that ifunc it the best solution then I
> suggest you look at the 1000s of packages in a Linux distro and see how
> many of them use IFUNC or any of the other suggested techniques.
>
> My survey shows very few.
Thats trivial take gentoo, where you could compile with -mcpu
But I am glad that you did survey.
You could finally answer a questions that I asked in first place.
1) Are among these packages some that use hwcap?
2) Do some use hwcap more than once in early initialization?
3) Did you do profiling to show that a hwcap optimization has some
performance impact?
You still didn't answer an objection that this harms packages that don't
use hwcap and we asked for examples to show that this proposal will help
in some cases. So far you didn't provided any justified example.
>
> So your issue is not with me but with the world at large.
>
> If you want this to be a serious option then you need to convince all of
> them.
Could you stop making strawman arguments? I never said that but from
start of mail:
> > > >>> One example would be write gcc pass that runs after early inlining to
> > > >>> find all functions containing __builtin_cpu_supports, cloning them to
> > > >>> replace it by constant and adding ifunc to automatically select variant.
Here you need to only convince gcc developers to use that. I also said
that your idea of application developers using that is a mistake and
they shouldn't touch that. Instead a distribution managers would package
these by adding appropriate gcc flags.