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 06/30/2015 04:07 PM, Steven Munroe wrote:
On Tue, 2015-06-30 at 07:49 +0100, Richard Henderson wrote:
This is not intended for use within GLIBC or by knowledgeable folks like
yourself and the GLIBC community.

This about application developers in other communities and users where I
would settle for them to just support my platform with any optimization
that is somewhat sane.

The __Builtin_cpu_supports exist and I see its use. I don't see much use
of the more "complicated" approaches that we use in GLIBC. So it seem
reasonable to enable __builtin_cpu_supports for POWER but define the
implementation to be optimal for the PowerPC platform.

Most the argument against seems to be based on assumed "moral hazard".
Where you think what they are doing is stupid and so you refuse to help
them with any mechanisms that might make what they are doing, and will
continue to do, a little less stupid.

No, this is mostly an argument against adding a new dependency between glibc and gcc, at a specific glibc version, which cannot be checked via symbol versioning.

On the other hand, there is an alternative way to implement what you want that, while a factor of 20 slower is not "slow" when the interface is used at the "approprate" level. And further, that the interface *is* handled by symbol versioning, and is also present in an older version of glibc and so the gcc feature is usable on more systems.

Surely that's a consideration worth a counter-argument?


r~


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