From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27041 invoked by alias); 26 Jun 2012 08:29:17 -0000 Received: (qmail 27028 invoked by uid 22791); 26 Jun 2012 08:29:14 -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-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Jun 2012 08:29:01 +0000 Received: by obcva7 with SMTP id va7so8469625obc.20 for ; Tue, 26 Jun 2012 01:28:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.131.2 with SMTP id oi2mr15121150obb.43.1340699339294; Tue, 26 Jun 2012 01:28:59 -0700 (PDT) Received: by 10.76.82.4 with HTTP; Tue, 26 Jun 2012 01:28:59 -0700 (PDT) In-Reply-To: References: <4FE26AFC.3000703@redhat.com> <4FE43AFD.6050601@redhat.com> Date: Tue, 26 Jun 2012 08:42:00 -0000 Message-ID: Subject: Re: New option to turn off stack reuse for temporaries From: Richard Guenther To: Xinliang David Li Cc: Jason Merrill , GCC Patches , Michael Matz 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-06/txt/msg01665.txt.bz2 On Mon, Jun 25, 2012 at 6:25 PM, Xinliang David Li wro= te: > Are there any more concerns about this patch? If not, I'd like to check i= t in. No - the fact that the flag is C++ specific but in common.opt is odd enough and -ftemp-reuse-stack sounds very very generic - which in fact it is not, it's a no-op in C. Is there a more formal phrase for the temporary kind th= at is affected? For me "temp" is synonymous to "auto" so I'd have expected the switch to turn off stack slot sharing for { int a[5]; } { int a[5]; } but that is not what it does. So - a little kludgy but probably more to wh= at I'd like it to be would be to move the option to c-family/c.opt enabled only for C++ and Obj-C++ and export it to the middle-end via a new langhook (the gimplifier code should be in Frontend code that lowers to GENERIC really and the WITH_CLEANUP_EXPR code should be C++ frontend specific ...). Thanks, Richard. > thanks, > > David > > On Fri, Jun 22, 2012 at 8:51 AM, Xinliang David Li w= rote: >> On Fri, Jun 22, 2012 at 2:39 AM, Richard Guenther >> wrote: >>> On Fri, Jun 22, 2012 at 11:29 AM, Jason Merrill wrot= e: >>>> On 06/22/2012 01:30 AM, Richard Guenther wrote: >>>>>> >>>>>> What other issues? It enables more potential code motion, but on the >>>>>> other hand, causes more conservative stack reuse. As far I can tell, >>>>>> the handling of temporaries is added independently after the clobber >>>>>> for scoped variables are introduced. This option can be used to >>>>>> restore the older behavior (in handling temps). >>>>> >>>>> >>>>> Well, it does not really restore the old behavior (if you mean before >>>>> adding >>>>> CLOBBERS, not before the single patch that might have used those for >>>>> gimplifying WITH_CLEANUP_EXPR). =A0You say it disables stack-slot sha= ring >>>>> for those decls but it also does other things via side-effects of no >>>>> longer >>>>> emitting the CLOBBER. =A0I say it's better to disable the stack-slot >>>>> sharing. >>>> >>>> >>>> The patch exactly restores the behavior of temporaries from before my = change >>>> to add CLOBBERs for temporaries. =A0The primary effect of that change = was to >>>> provide stack-slot sharing, but if there are other effects they are pr= obably >>>> desirable as well, since the broken code depended on the old behavior. >>> >>> So you see it as workaround option, like -fno-strict-aliasing, rather t= han >>> debugging aid? >> >> It can be used for both purposes -- if the violations are as pervasive >> as strict-aliasing cases (which looks like so). >> >> thanks, >> >> David >> >>> >>> Richard. >>> >>>> Jason