From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63033 invoked by alias); 29 Jan 2016 16:17:15 -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 63013 invoked by uid 89); 29 Jan 2016 16:17:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=two-step, weren't, werent, finalized X-HELO: e06smtp09.uk.ibm.com Received: from e06smtp09.uk.ibm.com (HELO e06smtp09.uk.ibm.com) (195.75.94.105) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 29 Jan 2016 16:17:11 +0000 Received: from localhost by e06smtp09.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 29 Jan 2016 16:17:07 -0000 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp09.uk.ibm.com (192.168.101.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 29 Jan 2016 16:17:04 -0000 X-IBM-Helo: d06dlp01.portsmouth.uk.ibm.com X-IBM-MailFrom: krebbel@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 ACAE117D805F for ; Fri, 29 Jan 2016 16:17:13 +0000 (GMT) Received: from d06av05.portsmouth.uk.ibm.com (d06av05.portsmouth.uk.ibm.com [9.149.37.229]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u0TGH3Pw9109810 for ; Fri, 29 Jan 2016 16:17:04 GMT Received: from d06av05.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u0TGH3c3019980 for ; Fri, 29 Jan 2016 09:17:03 -0700 Received: from [9.164.173.19] (icon-9-164-173-19.megacenter.de.ibm.com [9.164.173.19]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u0TGH3ep019962; Fri, 29 Jan 2016 09:17:03 -0700 Subject: Re: [PATCH] s390: Add -fsplit-stack support To: =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= References: <56993CC2.8090306@linux.vnet.ibm.com> <1452952000-603-1-git-send-email-koriakin@0x04.net> <20160129133344.GA29874@maggie> <56AB88B2.3020808@0x04.net> Cc: gcc-patches@gcc.gnu.org From: Andreas Krebbel Message-ID: <56AB907E.2010809@linux.vnet.ibm.com> Date: Fri, 29 Jan 2016 16:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56AB88B2.3020808@0x04.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16012916-0037-0000-0000-0000056CF36F X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg02321.txt.bz2 On 01/29/2016 04:43 PM, Marcin Kościelnicki wrote: > The testsuite with -fsplit-stack already hits all of them, and checking > them manually is rather tricky (I don't know if it could be done in > target-independent way at all), but I think it'd be reasonable to make > assembly testcases calling __morestack for the last two cases, to check > if the registers are being preserved, etc. Sounds good. Thanks! ... >>> + if (frame_size <= 0x7fff || (TARGET_EXTIMM && frame_size <= 0xffffffffu)) >> The agfi immediate value is a signed 32 bit integer. So you can only >> add up to 2G-1. I think it would be more readable to write this as: > > We're emitting ALGFI here, which accepts unsigned 32-bit integer. Ah right. Then it would be: if (CONST_OK_FOR_K (frame_size) || CONST_OK_FOR_Op (frame_size)) instead. >> >> if (CONST_OK_FOR_K (frame_size) || CONST_OK_FOR_Os (frame_size)) >> >> as in s390_emit_prologue. The Os check will check for TARGET_EXTIMM as well. > > Alright. ... >> I'm wondering if it is really necessary to expand the call in that >> two-step approach?! We do the general literal pool handling in >> s390_reorg because we need all the insn lengths to be finalized before >> performing the branch/pool splitting loop. But this shouldn't be necessary >> in this case. Would it be possible to expand the call already in >> emit_prologue phase and get rid of the s390_reorg part? > > There's an internal literal pool involved, which needs to be emitted as > one chunk. Optimizations are also very likely to destroy the sequence: > consider the target address that __morestack will call - the control > flow change happens in __morestack jump instruction, but the address > itself is encoded in one of the pool literals. Just not worth the risk. Ok. ... >>> + # OK, no stack allocation needed. We still follow the protocol and >>> + # call our caller - it doesn't cost much and makes sure vararg works. >>> + # No need to set any registers here - %r0 and %r2-%r6 weren't modified. >>> + basr %r14, %r10 # Call our caller. >> The comment confuses me. It somewhat sounds to me like the call >> wouldn't be really needed but in fact it cannot even remotely work >> without jumping back to the function body right?! > > Certainly. __morestack's task is to call the given function entry point > once the necessary stack space is established. In fact, in the no > allocation case, a sibling-call would actually be possible, if it > weren't for one annoying detail: there are no free GPRs we could use to > keep the address of the entry point - %r0 may be used to keep static > chain, %r1 may have to be the argument pointer, %r2-%r5 may be used to > keep parameters, and %r6-%r15 are callee-saved. Ok. The comment isn't about no-call vs. call it is about sibcall vs. call - got it. Bye, -Andreas-