From patchwork Fri May 7 16:26:27 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Stubbs X-Patchwork-Id: 1475591 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=) Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4FcG792PBkz9sSs for ; Sat, 8 May 2021 02:27:00 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A61403853803; Fri, 7 May 2021 16:26:57 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 1CF0D3853800 for ; Fri, 7 May 2021 16:26:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1CF0D3853800 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Andrew_Stubbs@mentor.com IronPort-SDR: EnpGHylykOouTd6iLGfSM9HgBX3XrtIMptf5b7vtnF4JDJ8EmawWRqRYtt5r/bB/hDrm6+2glT fDLZ/akH6fBjUKfpjWNEhYuGZ+zDp6bE/lF/jGubtViy1wTJFMzYVnwWtgEqO17I4c5hP6ERkG /N5Neg1OUMli2cUi+k40H+UebDqyWRJA9ES5YfDZK8LgJyj+WHAXY4cflUWOpM7/5rwVgreYfM JBAeGLuw4yvyhZIVAxJCmBfsONdWacAYkXW3sI5ykPx6I3Q3DHEIqtemSRyZXo6TTKZhSUmTNY 0WU= X-IronPort-AV: E=Sophos;i="5.82,281,1613462400"; d="scan'208";a="60967119" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 07 May 2021 08:26:53 -0800 IronPort-SDR: HZCOIkDVyOwg6P3JsfjIxh4Hchllg5QekWiMirIvqiNTGv2qq3hgx/kgGEaMlccMAT4Hqd3fjd UL3VDUKDRcgkvHMolSvjcnc7vpjKIiUk8JP2GLXM/KfbyMo55vhJX/IZMFTX+blFQA8ysjKbmn RCWzdumKHLreMrBtNzPk6OVh7G06HJlPVypdwnW9HQ3c3FvT6F+FbLkKdIoQniKuU1IJPZk6Uu SIOi7+QdWzzhWqYkfxnutM5TX+tSONYdpsnq40bxMWc/GVg+7a8BNfx+Yv8LUXtBuNszp73pzz yTQ= X-Mozilla-News-Host: news://news.gmane.org:119 To: "gcc-patches@gcc.gnu.org" From: Andrew Stubbs Subject: [PATCH] builtins.c: Ensure emit_move_insn operands are valid (PR100418) Message-ID: <6d405e80-365c-7e62-e36a-b6017a83795d@codesourcery.com> Date: Fri, 7 May 2021 17:26:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 Content-Language: en-GB X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" A recent patch from Alexandre added new calls to emit_move_insn with PLUS expressions in the operands. Apparently this works fine on (at least) x86_64, but fails on (at least) amdgcn, where the adddi3 patten has clobbers that the movdi3 does not. This results in ICEs in recog. This patch inserts force_operand around the problem cases so that it only creates valid move instructions. I've done a regression test on amdgcn and everything works again [*]. OK to commit? Andrew [*] Well, once I fix a new, unrelated TImode issue it does anyway. Ensure emit_move_insn operands are valid Some architectures are fine with PLUS in move instructions, but others are not (amdgcn is the motivating example). gcc/ChangeLog: PR target/100418 * builtins.c (try_store_by_multiple_pieces): Use force_operand for emit_move_insn operands. diff --git a/gcc/builtins.c b/gcc/builtins.c index 0db4090c434..ef8852418af 100644 --- a/gcc/builtins.c +++ b/gcc/builtins.c @@ -6773,9 +6773,10 @@ try_store_by_multiple_pieces (rtx to, rtx len, unsigned int ctz_len, /* Adjust PTR, TO and REM. Since TO's address is likely PTR+offset, we have to replace it. */ - emit_move_insn (ptr, XEXP (to, 0)); + emit_move_insn (ptr, force_operand (XEXP (to, 0), NULL_RTX)); to = replace_equiv_address (to, ptr); - emit_move_insn (rem, plus_constant (ptr_mode, rem, -blksize)); + rtx rem_minus_blksize = plus_constant (ptr_mode, rem, -blksize); + emit_move_insn (rem, force_operand (rem_minus_blksize, NULL_RTX)); } /* Iterate over power-of-two block sizes from the maximum length to @@ -6809,9 +6810,10 @@ try_store_by_multiple_pieces (rtx to, rtx len, unsigned int ctz_len, /* Adjust REM and PTR, unless this is the last iteration. */ if (i != sctz_len) { - emit_move_insn (ptr, XEXP (to, 0)); + emit_move_insn (ptr, force_operand (XEXP (to, 0), NULL_RTX)); to = replace_equiv_address (to, ptr); - emit_move_insn (rem, plus_constant (ptr_mode, rem, -blksize)); + rtx rem_minus_blksize = plus_constant (ptr_mode, rem, -blksize); + emit_move_insn (rem, force_operand (rem_minus_blksize, NULL_RTX)); } if (label)