From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11439 invoked by alias); 2 May 2012 18:04:19 -0000 Received: (qmail 11427 invoked by uid 22791); 2 May 2012 18:04:18 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-qa0-f47.google.com (HELO mail-qa0-f47.google.com) (209.85.216.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 May 2012 18:04:06 +0000 Received: by qabg1 with SMTP id g1so3002553qab.20 for ; Wed, 02 May 2012 11:04:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.183.76 with SMTP id cf12mr8883245qab.74.1335981845223; Wed, 02 May 2012 11:04:05 -0700 (PDT) Received: by 10.229.169.130 with HTTP; Wed, 2 May 2012 11:04:05 -0700 (PDT) In-Reply-To: References: <20120307004630.A503DB21B6@azwildcat.mtv.corp.google.com> Date: Wed, 02 May 2012 18:04:00 -0000 Message-ID: Subject: Re: User directed Function Multiversioning via Function Overloading (issue5752064) From: "H.J. Lu" To: Sriraman Tallam Cc: Richard Guenther , Jan Hubicka , Uros Bizjak , reply@codereview.appspotmail.com, gcc-patches@gcc.gnu.org, David Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-05/txt/msg00156.txt.bz2 On Wed, May 2, 2012 at 10:44 AM, Sriraman Tallam wrot= e: >>>> >>>> 1. =A0Since 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. =A0There is no way right >>> now to specify the order in which the dispatching should be done. >> >> This is very fragile. =A0We know ISAs and processors. =A0The 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. > > =A0Still, 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. =A0I don't see any tests for __builtin_cpu_supports ("XXX") >>>> nor __builtin_cpu_is ("XXX"). =A0I 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 checkin= g, ok. > Yes. BTW, I think you should also add FMA support to config/i386/i386-cpuinfo.c. Thanks. --=20 H.J.