On Wed, May 2, 2012 at 10:44 AM, Sriraman Tallam <tmsri...@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.
