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)


Hi,

Attached new patch with more bug fixes. I will fix the dispatching
method to use prioirty of attributes in the next iteration.

Patch also available for review here:  http://codereview.appspot.com/5752064

Thanks,
-Sri.

On Mon, May 7, 2012 at 9:58 AM, Sriraman Tallam <tmsriram@google.com> wrote:
> On Wed, May 2, 2012 at 11:04 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> 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.
>
> I am preparing a patch for this. I will send it your way soon enough.
>
> Thanks,
> -Sri.
>
>>
>> Thanks.
>>
>> --
>> H.J.

Attachment: mv_fe_patch.txt
Description: Text document


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