From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9992 invoked by alias); 4 Jul 2012 15:01:50 -0000 Received: (qmail 9980 invoked by uid 22791); 4 Jul 2012 15:01:49 -0000 X-SWARE-Spam-Status: No, hits=-5.6 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,TW_CF,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-lb0-f175.google.com (HELO mail-lb0-f175.google.com) (209.85.217.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Jul 2012 15:01:36 +0000 Received: by lbol5 with SMTP id l5so11366837lbo.20 for ; Wed, 04 Jul 2012 08:01:34 -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:x-system-of-record:x-gm-message-state; bh=ShaNzpoAHxO+wH5oGAT6aMaBOifbmKpAWrhkRXK2uVU=; b=YLn655uj5CbkViR7sdxYbdo6sdZ1i3vOt+Hof18lxEraCl55DwohtVYfOrXxwy/ZNq TN941Wr+J7Dn0DAc/mt/b9xC9J2TvUwlOK3wzLUPWvaOluI5rCWxeMYo5a3/931jk7cV ++2Xwq2LJ+WOrnsNqTLDSdIM4YnXS3Dfcpr3MoJQt3dqpqpddqZ9cVhT4c60ujYxpIh0 l0SqPih7pzz4+rTMAbrq1C7JF6CfpgV04aEhipMXIcPZlV7LjKjhwpHx8614zc+qVTTA UwF/J41NYkpCYDNdAL9Z3xJpDr4b1Q9/ZsfGXQiedPxCXVL6kffDZj4n2LXo/PtHxIeK P3TQ== Received: by 10.112.86.166 with SMTP id q6mr10176670lbz.6.1341414093661; Wed, 04 Jul 2012 08:01:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.86.166 with SMTP id q6mr10176661lbz.6.1341414093455; Wed, 04 Jul 2012 08:01:33 -0700 (PDT) Received: by 10.152.115.34 with HTTP; Wed, 4 Jul 2012 08:01:33 -0700 (PDT) In-Reply-To: References: <4FE26AFC.3000703@redhat.com> <4FE43AFD.6050601@redhat.com> Date: Wed, 04 Jul 2012 15:01:00 -0000 Message-ID: Subject: Re: New option to turn off stack reuse for temporaries From: Xinliang David Li To: Richard Guenther Cc: Jason Merrill , GCC Patches , Michael Matz Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnJqbCPU0GN8tigWn/7qZrjpZBeZ59/uv/RV9douv55i8vOsUFMbqzseAkBFYxV1nNo1CVGsMs2e1XJDGSyZ52mlBMHAeqaFZtS7o5/b+91PHNNJi1zO+c3s5TVE2jEyUY818jyQ1BUasa2XEngIht8lRfj4WawjjsufE1OOwZtsovt8lflLIiLUPHt6PtZW3IBwW2x 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/msg00150.txt.bz2 Comment? David On Mon, Jul 2, 2012 at 4:30 PM, Xinliang David Li wrote: > I extended the patch a little so that the option can be used to set > multiple stack reuse levels: -fstack-reuse=[all|name_vars|none] > > all: enable stack reuse for all local vars (named vars and compiler > generated temporaries) which live in memory; > name_vars: enable stack reuse only for user declared local vars with names; > none: disable stack reuse completely. > > Note the patch still chooses to suppress clobber statement generation > instead of just ignoring them in stack layout. This has the additional > advantage of allowing more aggressive code motion when stack use is > disabled. > > The documentation will be updated when the patch is agreed upon. > > thanks, > > David > > > On Thu, Jun 28, 2012 at 10:43 PM, Xinliang David Li wrote: >> (re-post in plain text) >> >> Moving this to cfgexpand time is simple and it can also be extended to >> handle scoped variables. However Jakub raised a good point about this >> being too late as stack space overlay is not the only way to cause >> trouble when the lifetime of a stack object is extended beyond the >> clobber stmt. >> >> thanks, >> >> David >> >> On Tue, Jun 26, 2012 at 1:28 AM, Richard Guenther >> wrote: >>> On Mon, Jun 25, 2012 at 6:25 PM, Xinliang David Li wrote: >>>> Are there any more concerns about this patch? If not, I'd like to check it 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 that >>> 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 what >>> 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 wrote: >>>>> On Fri, Jun 22, 2012 at 2:39 AM, Richard Guenther >>>>> wrote: >>>>>> On Fri, Jun 22, 2012 at 11:29 AM, Jason Merrill wrote: >>>>>>> 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). You say it disables stack-slot sharing >>>>>>>> for those decls but it also does other things via side-effects of no >>>>>>>> longer >>>>>>>> emitting the CLOBBER. I 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. The primary effect of that change was to >>>>>>> provide stack-slot sharing, but if there are other effects they are probably >>>>>>> desirable as well, since the broken code depended on the old behavior. >>>>>> >>>>>> So you see it as workaround option, like -fno-strict-aliasing, rather than >>>>>> 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