From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122927 invoked by alias); 17 Jul 2017 17:46:39 -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 122111 invoked by uid 89); 17 Jul 2017 17:46:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=cleaner, yea, Hx-languages-length:1678 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Jul 2017 17:46:36 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7477181233; Mon, 17 Jul 2017 17:46:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7477181233 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7477181233 Received: from localhost.localdomain (ovpn-116-17.phx2.redhat.com [10.3.116.17]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2702B6292E; Mon, 17 Jul 2017 17:46:34 +0000 (UTC) Subject: Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 From: Jeff Law To: Segher Boessenkool , Jeff Law Cc: gcc-patches References: <8a9cdbc9-dc96-e793-0147-3f09af2a26fa@gmail.com> <20170713014406.GX13471@gate.crashing.org> <59437b9f-e0d8-02dd-06fd-1b2542213cf0@redhat.com> Message-ID: <12b5442a-da33-c5ff-b076-6ebcb8a12802@redhat.com> Date: Mon, 17 Jul 2017 17:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <59437b9f-e0d8-02dd-06fd-1b2542213cf0@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00995.txt.bz2 On 07/13/2017 04:54 PM, Jeff Law wrote: > On 07/12/2017 07:44 PM, Segher Boessenkool wrote: >> I don't really see why this is so complicated, and why the rs6000 >> target changes (a later patch) are so big. Why isn't it just simple >> patches to allocate_stack (and the prologue thing), that check the >> flag and if it is set do some probes? > Yea. I wasn't happy with the size of the rs6000 patches either, which I > mentioned at some point :-) Some of the complexity is making sure we > keep the backchain pointer correct and trying to do so as efficiently as > possible. But there's too much conceptual code duplication. > > Essentially the code shows up 3 times in slightly different forms. So in the V2 patch the PPC code is somewhat cleaner. It's inherently going to be more complex than the other ports because it has to handle dynamic allocation and probing on its own rather than relying on the generic code. What I've done is broken out a few helper functions in that generic code that the ppc backend can use. There's helpers that compute the key information we need (rounded size, last address, residual allocation, etc), code to emit the start of the loop and code to emit the end of the loop. So the PPC dynamic code in rs6000.md looks something like this now compute_data (...) if (loop needed) { emit_loop_start (...); ppc magic to allocate & probe a stack page emit_loop_end (...); } if (residuals) { fix operands[1] and let the rest of the expander run } Ideally those three helpers could be used by other ports that have backend specific expanders to handle dynamic stack allocations. Jeff