From patchwork Tue Nov 10 22:58:27 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexandre Oliva X-Patchwork-Id: 542641 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 4ABBD140D97 for ; Wed, 11 Nov 2015 09:59:26 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=L6X0SThw; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; q=dns; s=default; b=Da7RtH1trnY+Z16g V8HfWYp+O/Y3aOfyFsprSf1Nhd3qMBaMykAA2F9R1RHSqNOjsw1OvfMtt9dtbdIM EdXD77mxCggdG/i9Gl7NJ/OFtUj6SyjVz6pKKOevTG1Go0oIQuvHPOFH4d9h6cUC /2e3EhbBHcpxmwpeEPk/BgubYLE= 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:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; s=default; bh=0tVe5eANeTMfhXJJd6ksMK L4v9s=; b=L6X0SThwa7rWZbrt9ANUdEB9NeJstF1H16aC2inHIAUqZY134vhwtU yGeKRhHtFaxL7dO9Mcohkx7WOys/V2aJBGF+8e8z/Wdxy2kBqg9spj7WT8GgXOZ/ 6e0l/kvE+1zFhMiA/mo4gOCAsKB1IKOeco3M1b0gYWzx/7eOi2kz4= Received: (qmail 9093 invoked by alias); 10 Nov 2015 22:59:17 -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 9049 invoked by uid 89); 10 Nov 2015 22:59:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 10 Nov 2015 22:59:15 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id AE0C2552E8; Tue, 10 Nov 2015 22:59:13 +0000 (UTC) Received: from freie.home (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAAMxAjG013326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Nov 2015 17:59:13 -0500 Received: from livre.home (livre.home [172.31.160.2]) by freie.home (8.15.2/8.15.2) with ESMTP id tAAMwSx6017125; Tue, 10 Nov 2015 20:58:28 -0200 From: Alexandre Oliva To: Alan Lawrence Cc: "gcc-patches\@gcc.gnu.org" , Marcus Shawcroft , James Greenhalgh Subject: Re: [PR64164] drop copyrename, integrate into expand References: <20150723203112.GB27818@gate.crashing.org> <20150810082355.GA31149@arm.com> <55C8BFC3.3030603@redhat.com> <55E72D4C.40705@arm.com> <55FC3171.7040509@arm.com> <56420DC4.3070407@arm.com> Date: Tue, 10 Nov 2015 20:58:27 -0200 In-Reply-To: <56420DC4.3070407@arm.com> (Alan Lawrence's message of "Tue, 10 Nov 2015 15:31:16 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 On Nov 10, 2015, Alan Lawrence wrote: > FAIL: gcc.target/aarch64/aapcs64/func-ret-4.c execution, -O2 Ugh, sorry. I even checked that testcase by hand before submitting the patch, because I knew it took the paths I was changing, but I didn't realize the stack store and load would amount to shifts when the stack slot was bypassed. With the following patch, we get a lsr and a ubfx, without the sp adjustments. Please let me know if it causes any further problems. So far, I've tested it on x86_64-linux-gnu, i686-linux-gnu, and ppc64le-linux-gnu; the ppc64-linux-gnu test run is running slower and probably won't be done before I call it a day, but I wanted to give you something before taking off for the day. Is this ok to install if ppc64-linux-gnu also regstraps successfully? [PR67753] adjust for padding when bypassing memory in assign_parm_setup_block From: Alexandre Oliva Storing a register in memory as a full word and then accessing the same memory address under a smaller-than-word mode amounts to right-shifting of the register word on big endian machines. So, if BLOCK_REG_PADDING chooses upward padding for BYTES_BIG_ENDIAN, and we're copying from the entry_parm REG directly to a pseudo, bypassing any stack slot, perform the shifting explicitly. This fixes the miscompile of function_return_val_10 in gcc.target/aarch64/aapcs64/func-ret-4.c for target aarch64_be-elf introduced in the first patch for 67753. for gcc/ChangeLog PR rtl-optimization/67753 PR rtl-optimization/64164 * function.c (assign_parm_setup_block): Right-shift upward-padded big-endian args when bypassing the stack slot. --- gcc/function.c | 44 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 41 insertions(+), 3 deletions(-) diff --git a/gcc/function.c b/gcc/function.c index a637cb3..1ee092c 100644 --- a/gcc/function.c +++ b/gcc/function.c @@ -3002,6 +3002,38 @@ assign_parm_setup_block (struct assign_parm_data_all *all, emit_move_insn (change_address (mem, mode, 0), reg); } +#ifdef BLOCK_REG_PADDING + /* Storing the register in memory as a full word, as + move_block_from_reg below would do, and then using the + MEM in a smaller mode, has the effect of shifting right + if BYTES_BIG_ENDIAN. If we're bypassing memory, the + shifting must be explicit. */ + else if (!MEM_P (mem)) + { + rtx x; + + /* If the assert below fails, we should have taken the + mode != BLKmode path above, unless we have downward + padding of smaller-than-word arguments on a machine + with little-endian bytes, which would likely require + additional changes to work correctly. */ + gcc_checking_assert (BYTES_BIG_ENDIAN + && (BLOCK_REG_PADDING (mode, + data->passed_type, 1) + == upward)); + + int by = (UNITS_PER_WORD - size) * BITS_PER_UNIT; + + x = gen_rtx_REG (word_mode, REGNO (entry_parm)); + x = expand_shift (RSHIFT_EXPR, word_mode, x, by, + NULL_RTX, 1); + x = force_reg (word_mode, x); + x = gen_lowpart_SUBREG (GET_MODE (mem), x); + + emit_move_insn (mem, x); + } +#endif + /* Blocks smaller than a word on a BYTES_BIG_ENDIAN machine must be aligned to the left before storing to memory. Note that the previous test doesn't @@ -3023,14 +3055,20 @@ assign_parm_setup_block (struct assign_parm_data_all *all, tem = change_address (mem, word_mode, 0); emit_move_insn (tem, x); } - else if (!MEM_P (mem)) - emit_move_insn (mem, entry_parm); else move_block_from_reg (REGNO (entry_parm), mem, size_stored / UNITS_PER_WORD); } else if (!MEM_P (mem)) - emit_move_insn (mem, entry_parm); + { + gcc_checking_assert (size > UNITS_PER_WORD); +#ifdef BLOCK_REG_PADDING + gcc_checking_assert (BLOCK_REG_PADDING (GET_MODE (mem), + data->passed_type, 0) + == upward); +#endif + emit_move_insn (mem, entry_parm); + } else move_block_from_reg (REGNO (entry_parm), mem, size_stored / UNITS_PER_WORD);