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] |
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] |