RFC: Test optimizations for multiple architectures

H.J. Lu hjl.tools@gmail.com
Fri Nov 12 14:46:00 GMT 2010


On Fri, Nov 12, 2010 at 1:15 AM, Ulrich Drepper <drepper@gmail.com> wrote:
> On Thu, Nov 11, 2010 at 12:33, Roland McGrath <roland@redhat.com> wrote:
>> I'd be more inclined to provide some mechanism to mask the feature flags
>> that are used to decide which function to chose, somewhat analogous to
>> LD_HWCAP_MASK.
>
> This doesn't work in general and no scheme which would select a
> specific function from the outside will work.  Not unless we'd be
> willing to accept a new flag for every new implementation.  Fact is
> that the code in the ifunc selector functions does not have to use
> just CPU features.  We are already using in some processor models and
> not features.  This variety will undoubtedly increase over time.  This
> all ignores that having an overwrite at runtime is a) adding more
> overhead and b) adding yet another way for people to screw up their
> environments.

Totally agree.

> The way to handle this is to explicitly run the tests by adding the
> real function name as referenced in the ifunc selector functions to
> the list of functions we iterate over to run the tests.  This is what
> I think HJ's patch does.  Perhaps it needs to be cleaned up but it the

That is exactly what my patch does. libc_func returns the list of
functions we iterate over to run the tests on the build machine.
I appreciate any suggestions to clean it up.

> right way to do.  Every time a new variant is added we can extend the
> list for the architecture.  The complexity from running a newer
> variant on an older machine can also quite easily be abstracted out.

Exactly.

> What has to be done can be hidden in some arch-specific headers and
> the tests will then use the included definitions if they exist or fall
> back to the simple testing we do today.  All that'll be needed in
> future is to remember to add thename of the new variant to the
> appropriate list.
>

That is exactly how my patch works.

Thanks.

-- 
H.J.



More information about the Libc-alpha mailing list