Re: RFC: Test optimizations for multiple architectures

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.