This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]