This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: User directed Function Multiversioning via Function Overloading (issue5752064)


On Wed, May 2, 2012 at 10:44 AM, Sriraman Tallam <tmsriram@google.com> wrote:
>>>>
>>>> 1. ?Since AVX > SSE4 > SSSE3 > SSE3 > SSE2 > SSE, with
>>>> foo for AVX and SSE3, on AVX processors, which foo will be
>>>> selected?
>>>
>>> foo for AVX will get called since that appears ahead.
>>>
>>> The dispatching is done in the same order in which the functions are
>>> specified. If, potentially, two foo versions can be dispatched for an
>>> architecture, the first foo will get called. ?There is no way right
>>> now to specify the order in which the dispatching should be done.
>>
>> This is very fragile. ?We know ISAs and processors. ?The source
>> order should be irrelevant.
>
> I am not sure it is always possible keep this dispatching unambiguous
> to the user. It might be better to let the user specify a priority for
> each version to control the order of dispatching.
>
> ?Still, one way to implement what you said is to assign a significance
> number to each ISA, where the number of sse4 > sse, for instance.
> Then, the dispatching can be done in the descending order of
> significance. What do you think?

This sounds reasonable.  You should also take processor into
account when doing this.

> I thought about this earlier and I was thinking along the lines of
> letting the user specify a priority for each version, when there is
> ambiguity.
>
>>
>>>
>>>> 2. ?I don't see any tests for __builtin_cpu_supports ("XXX")
>>>> nor __builtin_cpu_is ("XXX"). ?I think you need tests for
>>>> them.
>>>
>>> This is already there as part of the previous CPU detection patch that
>>> was submitted. Please see gcc.target/i386/builtin_target.c. Did you
>>> want something else?
>>
>> gcc.target/i386/builtin_target.c doesn't test if __builtin_cpu_supports ("XXX")
>> and __builtin_cpu_is ("XXX") are implemented correctly.
>
> Oh, you mean like doing a CPUID again in the test case itself and checking, ok.
>

Yes. BTW,  I think you should also add FMA support to
config/i386/i386-cpuinfo.c.

Thanks.

-- 
H.J.


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