From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18437 invoked by alias); 30 Jul 2012 19:01:30 -0000 Received: (qmail 18409 invoked by uid 22791); 30 Jul 2012 19:01:27 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-gh0-f175.google.com (HELO mail-gh0-f175.google.com) (209.85.160.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Jul 2012 19:01:14 +0000 Received: by ghbz2 with SMTP id z2so5243871ghb.20 for ; Mon, 30 Jul 2012 12:01:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=qzstrP//aJxfkBwZ6Ps2wPHyoorE1t8j3Rb+tqjxr8c=; b=MsmBR4zQXFRDOoLfA014GPcT4vfg4qmRG6gjI1ny92b+aFMptdWuj0ENdWZIiqdQPZ 2LM+NhKTBIX1PScF6vOkAdpYl0TnlM0Mbk7lkj0Ea5iq3kO+37Ae/NDKrq2o1yeJAWy+ 1C83lZDKxrgTY/qefZ7fAXfAtr8Qzr9v7ZQERYy2uCy+F7PyDQ18+iGJmId27kM2RjG/ SGX2xO5W9V4HrsDvGzL79t/YAF2vuo2+yYCyeg6nLSwZRhPYYSm6F7sYsndaqn0REApO 4lwvaqynZzBcBPYrNxIG593OieYd5IJRTlOSdINFxCZwDgnYcPhMtIudFdiQ0gfvTIYN JIng== Received: by 10.60.0.161 with SMTP id 1mr18767019oef.63.1343674873738; Mon, 30 Jul 2012 12:01:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.0.161 with SMTP id 1mr18767001oef.63.1343674873581; Mon, 30 Jul 2012 12:01:13 -0700 (PDT) Received: by 10.182.9.167 with HTTP; Mon, 30 Jul 2012 12:01:13 -0700 (PDT) In-Reply-To: <5008708E.1030109@redhat.com> References: <20120307004630.A503DB21B6@azwildcat.mtv.corp.google.com> <4FF7D1C6.90407@redhat.com> <4FF96D0C.5060406@redhat.com> <4FFBF9F5.6020306@redhat.com> <5008708E.1030109@redhat.com> Date: Mon, 30 Jul 2012 19:16:00 -0000 Message-ID: Subject: Re: User directed Function Multiversioning via Function Overloading (issue5752064) From: Sriraman Tallam To: Jason Merrill Cc: Xinliang David Li , mark@codesourcery.com, nathan@codesourcery.com, "H.J. Lu" , Richard Guenther , Jan Hubicka , Uros Bizjak , reply@codereview.appspotmail.com, gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlkG0xbeOg/kWLtsTodNC9bD8Ny2a1xia0533V4Ftj4tcTsJ8Ns41hS/bSQ6dO69mobjejt7KWQfYWalsjcZOI7AhfgmqJu5vNPwqHrFLrs2nogm1CD7iSE34noLTzJzGvaiyHI2+F5EYa976+LAbZmS4atNQdiFhnCrEItzBagYFFbnr+UsSnYCmgK+M5bzwXLefru 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-07/txt/msg01508.txt.bz2 On Thu, Jul 19, 2012 at 1:39 PM, Jason Merrill wrote: > > On 07/10/2012 03:14 PM, Sriraman Tallam wrote: >> >> I am using the questions you asked previously >> to explain how I solved each of them. When working on this patch, these >> are the exact questions I had and tried to address it. >> >> * Does this attribute affect a function signature? >> >> The function signature should be changed when there is more than one >> definition/declaration of foo distinguished by unique target attributes. > > >[...] > > I agree. I was trying to suggest that these questions are what the front= end needs to care about, not about versioning specifically. If these ques= tions are turned into target hooks, all of the logic specific to versioning= can be contained in the target. > > My only question intended to be answered by humans is, do people think mo= ving the versioning logic behind more generic target hooks is worthwhile? I have some comments related For the example below, // Default version. int foo () { ..... } // Version XXX feature supported by Target ABC. int foo __attribute__ ((target ("XXX"))) { .... } How should the second version of foo be treated for targets where feature XXX is not supported? Right now, I am working on having my patch completely ignore such function versions when compiled for targets that do not understand the attribute. I could move this check into a generic target hook so that a function definition that does not make sense for the current target is ignored. Also, currently the patch uses target hooks to do the following: - Find if a particular version can be called directly, rather than go through the dispatcher. - Determine what the dispatcher body should be. - Determining the order in which function versions must be dispatched. I do not have a strong opinion on whether the entire logic should be based on target hooks. Thanks, -Sri. > > > > Jason