From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108204 invoked by alias); 7 Jul 2016 11:57:27 -0000 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 Received: (qmail 108190 invoked by uid 89); 7 Jul 2016 11:57:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,RCVD_IN_SEMBACKSCATTER autolearn=no version=3.3.2 spammy=H*r:4.76, H*m:linux, Hx-languages-length:1993 X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 07 Jul 2016 11:57:25 +0000 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u67BsZck052173 for ; Thu, 7 Jul 2016 07:57:22 -0400 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0b-001b2d01.pphosted.com with ESMTP id 2415xn849r-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 07 Jul 2016 07:57:22 -0400 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 7 Jul 2016 12:57:20 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 7 Jul 2016 12:57:18 +0100 X-IBM-Helo: d06dlp01.portsmouth.uk.ibm.com X-IBM-MailFrom: vogt@linux.vnet.ibm.com X-IBM-RcptTo: gcc-patches@gcc.gnu.org Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 05D5817D805D for ; Thu, 7 Jul 2016 12:58:42 +0100 (BST) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u67BvIqU45416574 for ; Thu, 7 Jul 2016 11:57:18 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u67BvHFs026020 for ; Thu, 7 Jul 2016 05:57:17 -0600 Received: from bl3ahm9f.de.ibm.com (dyn-9-152-212-182.boeblingen.de.ibm.com [9.152.212.182]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u67BvGf5026004; Thu, 7 Jul 2016 05:57:16 -0600 Received: from dvogt by bl3ahm9f.de.ibm.com with local (Exim 4.76) (envelope-from ) id 1bL7vg-0006pO-7b; Thu, 07 Jul 2016 13:57:16 +0200 Date: Thu, 07 Jul 2016 11:57:00 -0000 From: Dominik Vogt To: Bernd Schmidt Cc: Jeff Law , gcc-patches@gcc.gnu.org, Andreas Krebbel , Ulrich Weigand , Andreas Arnez Subject: Re: [PATCH v2] Allocate constant size dynamic stack space in the prologue Reply-To: vogt@linux.vnet.ibm.com Mail-Followup-To: vogt@linux.vnet.ibm.com, Bernd Schmidt , Jeff Law , gcc-patches@gcc.gnu.org, Andreas Krebbel , Ulrich Weigand , Andreas Arnez References: <20151125125610.GA19687@linux.vnet.ibm.com> <20160506093747.GA22977@linux.vnet.ibm.com> <20160506094415.GA23043@linux.vnet.ibm.com> <03ecb4c1-3d2f-0ff7-1110-7519a5106d5a@redhat.com> <20160623154814.GA23280@linux.vnet.ibm.com> <20160624123044.GA12401@linux.vnet.ibm.com> <20160704121955.GA9654@linux.vnet.ibm.com> <8f09eb18-0159-5fc7-8004-161466bfb349@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f09eb18-0159-5fc7-8004-161466bfb349@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16070711-0016-0000-0000-000002066F53 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16070711-0017-0000-0000-0000222CD3CD Message-Id: <20160707115716.GA14409@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-07_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607070112 X-SW-Source: 2016-07/txt/msg00302.txt.bz2 On Wed, Jul 06, 2016 at 02:01:06PM +0200, Bernd Schmidt wrote: > There's one thing I don't quite understand and which seems to have > changed since v1: > > On 07/04/2016 02:19 PM, Dominik Vogt wrote: > >@@ -1099,8 +1101,10 @@ expand_stack_vars (bool (*pred) (size_t), struct stack_vars_data *data) > > > > /* If there were any, allocate space. */ > > if (large_size > 0) > >- large_base = allocate_dynamic_stack_space (GEN_INT (large_size), 0, > >- large_align, true); > >+ { > >+ large_allocsize = GEN_INT (large_size); > >+ get_dynamic_stack_size (&large_allocsize, 0, large_align, NULL); > >+ } > > } > > > > for (si = 0; si < n; ++si) > >@@ -1186,6 +1190,19 @@ expand_stack_vars (bool (*pred) (size_t), struct stack_vars_data *data) > > /* Large alignment is only processed in the last pass. */ > > if (pred) > > continue; > >+ > >+ if (large_allocsize && ! large_allocation_done) > >+ { > >+ /* Allocate space the virtual stack vars area in the > >+ prologue. */ > >+ HOST_WIDE_INT loffset; > >+ > >+ loffset = alloc_stack_frame_space > >+ (INTVAL (large_allocsize), > >+ PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT); > >+ large_base = get_dynamic_stack_base (loffset, large_align); > >+ large_allocation_done = true; > >+ } > > gcc_assert (large_base != NULL); > > > > Why is this code split between the two places here? This is a bugfix from v1 to v2. I think I had to move this code to the second loop so that the space for dynamically aligned variables is allocated at the "end" of the space for stack variables. I cannot remember what the bug was, but maybe it was that the variables with fixed and static alignment ended up at the same address. Anyway, now that the new allocation strategy is used unconditionally, it should be possible to move the get_dynamic_stack_size call down to the second loop and simplify the code somewhat. I'll look into that. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany