From patchwork Fri Dec 19 23:45:51 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John David Anglin X-Patchwork-Id: 423012 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3FB0314009B for ; Sat, 20 Dec 2014 10:46:22 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:cc:from:to:in-reply-to:content-type:mime-version :subject:date:references; q=dns; s=default; b=VniNI1wy5f1k6sQhkM KkqUT7ly2L4+oL52RsSkgArtMgQGoggwdR55PvBWuBco74dW96sf6UwX+0WfyMOV auiV24+x/HdEEnFhT9DmcvNLsp/mQQVFcQrgH4A0DKgWKOEsKsKPo61q/gt8Rgzd pyzFRAa8TnU5BRu2Y6cf7aqJE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:cc:from:to:in-reply-to:content-type:mime-version :subject:date:references; s=default; bh=K8/vU3QJSUhFZb8mVCDCK5Dd MWs=; b=WZ48cZyjvJD58uNNTj6hEoYTUmN5aZ2TsDGIF+TFYMbTJszcs7BxjEAT noyq+uk5uM+UoFZ2iqbwl/GqN4xGpo3Wn8j+cHQhKCWYQLFljOgLhdAgzQXj6BMG nJrYKZIVY28/td0LIGrXWGraVoMxPQxSIE82GE2Yoyky2eKbXgw= Received: (qmail 8055 invoked by alias); 19 Dec 2014 23:46:14 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 8040 invoked by uid 89); 19 Dec 2014 23:46:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 X-HELO: BLU004-OMC3S16.hotmail.com Received: from blu004-omc3s16.hotmail.com (HELO BLU004-OMC3S16.hotmail.com) (65.55.116.91) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Fri, 19 Dec 2014 23:46:11 +0000 Received: from BLU436-SMTP53 ([65.55.116.74]) by BLU004-OMC3S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 19 Dec 2014 15:46:10 -0800 X-TMN: [2B1Uv9Tvoa/S7IZGHLkadfWfUupv1ibW] Message-ID: CC: Jeff Law , GCC Patches From: John David Anglin To: John David Anglin In-Reply-To: MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: [PATCH] Treat a sibling call as though it does a wild read Date: Fri, 19 Dec 2014 18:45:51 -0500 References: <547C9DEC.6030803@redhat.com> <5486039B.1000107@redhat.com> <548627E0.2020206@redhat.com> On 16-Dec-14, at 8:17 PM, John David Anglin wrote: > On 8-Dec-14, at 5:36 PM, Jeff Law wrote: > >> On 12/08/14 15:15, John David Anglin wrote: >>> On 12/8/2014 3:01 PM, Jeff Law wrote: >>>>> The above is wrong for sibcalls. Sibcall arguments are relative >>>>> to the incoming argument pointer. Is this always the frame >>>>> pointer? >>>> I don't think it's always the frame pointer. Don't we use an >>>> argument pointer for the PA64 runtime? If I recall, it was the >>>> only port that had a non-eliminable argument pointer at the time. >>> I don't think PA64 is an argument against this as sibcalls don't >>> work >>> in the PA64 runtime (they are disabled in pa.c) because the argument >>> pointer isn't a fixed register. I guess in theory it could be fixed >>> if it was saved and restored across calls. >> But there's nothing that says another port in the future won't have >> similar characteristics as the PA, so while the PA isn't >> particularly important, it shows there's cases where arguments >> won't be accessed by the FP. >> >> >>> >>> DSE as it stands doesn't look at argument pointer based stores and I >>> suspect they would be deleted with current code. >> Agreed. > > > I believe that this version addresses the above issues. While there > may be some opportunity to > optimize the handling of sibling call arguments, I think it is more > important to get the overall logic > correct. Also, it's obviously a rare situation for the arguments to > be pushed to the stack. > > Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11. > > Okay? Sorry, forgot to append testcase and ChangeLog entry for it. Dave --- John David Anglin dave.anglin@bell.net 2014-12-16 John David Anglin PR target/55023 * dse.c (scan_insn): Treat sibling call as though it does a wild read. * gcc.dg/pr55023.c: New file. Index: dse.c =================================================================== --- dse.c (revision 218616) +++ dse.c (working copy) @@ -2483,6 +2483,17 @@ insn_info->cannot_delete = true; + /* Arguments for a sibling call that are pushed to memory are passed + using the incoming argument pointer of the current function. These + may or may not be frame related depending on the target. Since + argument pointer related stores are not currently tracked, we treat + a sibling call as though it does a wild read. */ + if (SIBLING_CALL_P (insn)) + { + add_wild_read (bb_info); + return; + } + /* Const functions cannot do anything bad i.e. read memory, however, they can read their parameters which may have been pushed onto the stack. --- /dev/null 2014-11-28 19:44:51.440000000 -0500 +++ gcc/testsuite/gcc.dg/pr55023.c 2014-12-04 19:49:45.887701600 -0500 @@ -0,0 +1,33 @@ +/* PR rtl-optimization/55023 */ +/* { dg-do run } */ +/* { dg-options "-O2 -fno-inline" } */ + +extern void abort (void); +typedef long long int64_t; + +struct foo { + int x; + int y; +}; + +int64_t foo(int64_t a, int64_t b, int64_t c) +{ + return a + b + c; +} + +int64_t bar(int64_t a, struct foo bq, struct foo cq) +{ + int64_t b = bq.x + bq.y; + int64_t c = cq.x + cq.y; + return foo(a, b, c); +} + +int main(void) +{ + int64_t a = 1; + struct foo b = { 2, 3 }; + struct foo c = { 4, 5 }; + if (bar (a, b, c) != 15) + abort (); + return 0; +}