From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2619 invoked by alias); 13 Feb 2013 19:54:27 -0000 Received: (qmail 2607 invoked by uid 22791); 13 Feb 2013 19:54:26 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Feb 2013 19:54:15 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1DJsF5r025004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Feb 2013 14:54:15 -0500 Received: from zalov.redhat.com (vpn1-6-84.ams2.redhat.com [10.36.6.84]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1DJsDql005091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Feb 2013 14:54:14 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id r1DJsCwh010805; Wed, 13 Feb 2013 20:54:12 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r1DJs6HX010804; Wed, 13 Feb 2013 20:54:06 +0100 Date: Wed, 13 Feb 2013 19:54:00 -0000 From: Jakub Jelinek To: Aldy Hernandez Cc: gcc-patches , rdsandiford@googlemail.com Subject: Re: PR target/52555: attribute optimize is overriding command line options Message-ID: <20130213195406.GA4385@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <51198989.7090803@redhat.com> <20130212140503.GD4385@tucnak.redhat.com> <878v6twl42.fsf@talisman.default> <511A7BBF.1030401@redhat.com> <874nhhwhvi.fsf@talisman.default> <511BCFC2.6070601@redhat.com> <874nhgumeg.fsf@talisman.default> <511BD678.2090206@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <511BD678.2090206@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2013-02/txt/msg00644.txt.bz2 On Wed, Feb 13, 2013 at 12:07:52PM -0600, Aldy Hernandez wrote: > >Sorry, just noticed: > > > >>+ /* If the optabs changed, record it in the node. */ > >>+ if (memcmp (tmp_target_optabs, &default_target_optabs, > >>+ sizeof (struct target_optabs))) > > > >This should be this_target_optabs rather than &default_target_optabs. > >Nothing but target code and initialisers should use &default_target_optabs > >directly. > > Fixed. > > > > >I don't think that needs a retest though. It only makes a difference > >on MIPS. > > I verified that the testcase is still fixed by this patch (just in > case). Thanks so much for the review. > > Final patch attached. Actually, thinking more about SWITCHABLE_TARGETS, I don't think this works at all on those targets. this_target_optab is some random optab from whatever has been left there by previous function, it can be either the same, or different target (mips vs. mips16?). So, for SWITCHABLE_TARGETS, I'm afraid you really can't save the optabs in the optimization node (because, there could be different optabs for say all of -Ofast + mips, -Ofast + mips16, -O2 + mips and -O2 + mips16 combinations), but you probably can't save it even from within the target hook, because some non-default optimization node might be in effect. So, for SWITCHABLE_TARGETS, I think you can only save it in cfun->this_fn_optab or similar, and perhaps cache the default for mips16 only when you know the default optimization node is in effect (or force it into effect temporarily). For !SWITCHABLE_TARGETS, you can easily remember it in the optimization nodes and just copy the pointer over to cfun->this_fn_optab. And unfortunately it seems optimize attribute is supported everywhere, just the target attribute is not. But, as soon as it is reachable from cfun->this_fn_optab, we might need to GC allocate it, while optimization nodes are never freed, cfun is freed I think. Jakub