From patchwork Thu Jul 4 18:54:14 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roger Sayle X-Patchwork-Id: 1956997 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=nextmovesoftware.com header.i=@nextmovesoftware.com header.a=rsa-sha256 header.s=default header.b=Z2zESe9v; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4WFQmy25KXz1xqb for ; Fri, 5 Jul 2024 04:54:42 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 76DC3384A45E for ; Thu, 4 Jul 2024 18:54:40 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from server.nextmovesoftware.com (server.nextmovesoftware.com [69.48.154.134]) by sourceware.org (Postfix) with ESMTPS id 5ED69386100D for ; Thu, 4 Jul 2024 18:54:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5ED69386100D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nextmovesoftware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nextmovesoftware.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5ED69386100D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=69.48.154.134 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720119258; cv=none; b=RMik+sdu9/TmqtUdKR52A+m1V2+hlLm4Yrg7hVEVEDjxdoXuSXj5hErDSxtZDZ9reYHFY5NIpGa8rtc8FgZoyDEKcJV+7lWgBEeI0Ptwp/Z3p6I9D3g63VnQePgOFQz3ue1od9Wzsa31rnVpUJB6hFQTZYpau70B/h5c/cuQrM4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720119258; c=relaxed/simple; bh=4KhPUQ/DAxxGzhYxfzBXYqWyw6jGJxy7OkAjsCHha0Y=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=D9BmKeiQXqm4IHCrHrLp+dC7WJnbLQpuqJS7WhXrQUSa17zEtm0LXw/9jAiM7k07pUZk4FyhTtAQqqfxHCc+rbZl41Yw34gM5+7LvbI2IYaX4SIdIXw5uqjtcEncCGo/YogB03kV1X8UIYyVxKnoeyGG6uPyOqkfJOCV13apRzc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nextmovesoftware.com; s=default; h=Content-Type:MIME-Version:Message-ID: Date:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=+Hg+EO13A44yWjrLFeXxNezlJcbSQhnGpk8p8zZdnB0=; b=Z2zESe9v7qpjCiGJC3YPhdv4Ac bc3vJSxOB+/ROxiRstJSML2TjOgkrYdszGq0cRlQwgsbflu+5zLFNILuiSoT0dcKSEyKMpVAt1fUV Had2BtKvGlQO6334VIGhPmpEJA+YLcJ4OP0adRJqc0JHVw0OJpBS7OS3SS6hTllLw23DCLrjsrdoe V8J/MEF9MCWWqAjNDEd1sP3NwQ9q4Hr2I4F77d9P2mhJljS/3u+PkXM0HrKEZyg+oC2zTUvAu3QfC VFXactCEJPlvfdRotGJFwze094+VJXlsa4K5IpoY507f327b70gXU7cfA4J8fmOOT1E3/anCF96Wp eCE80tZA==; Received: from [185.62.158.67] (port=51701 helo=Dell) by server.nextmovesoftware.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1sPRay-00000008wkW-35DM; Thu, 04 Jul 2024 14:54:16 -0400 From: "Roger Sayle" To: Cc: "'Hongtao Liu'" , "'Uros Bizjak'" Subject: [x86 SSE PATCH] PR target/115751: Avoid force_reg in ix86_expand_ternlog. Date: Thu, 4 Jul 2024 19:54:14 +0100 Message-ID: <01d101dace43$91fae2c0$b5f0a840$@nextmovesoftware.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdrOQ2HFauszSLc+QqCaf1he2YIgmg== Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.nextmovesoftware.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nextmovesoftware.com X-Get-Message-Sender-Via: server.nextmovesoftware.com: authenticated_id: roger@nextmovesoftware.com X-Authenticated-Sender: server.nextmovesoftware.com: roger@nextmovesoftware.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org This patch fixes a problem with splitting of complex AVX512 ternlog instructions on x86_64. A recent change allows the ternlog pattern to have multiple mem-like operands prior to reload, by emitting any "reloads" as necessary during split1, before register allocation. The issue is that this code calls force_reg to place the mem-like operand into a register, but unfortunately the vec_duplicate (broadcast) form of operands supported by ternlog isn't considered a "general_operand", i.e. supported by all instructions. This mismatch triggers an ICE in the middle-end's force_reg, even though the x86 supports loading these vec_duplicate operands into a vector register in a single (move) instruction. This patch resolves this problem by replacing force_reg with calls to gen_reg_rtx and emit_move (as the i386 backend, unlike the middle-end, knows these will be recognized by recog). I'll admit that I've been unable to reproduce this error without a testcase, but my assumption when developing the previous patch was that was safe to call force_reg on a vec_duplicate, which this PR shows to be wrong (currently). I'll let smarter minds pronounce on whether changing i386.md's definition of general_operand may be an alternate solution, but such a change can be independent of this fix. [I've a related patch to expand the CONST_VECTORs allowed in ix86_legitimate_constant_p before reload, but keeping everything happy is tricky]. This patch has been tested on x86_64-pc-linux-gnu with make bootstrap and make -k check, both with and without --target_board=unix{-m32} with no new failures. Ok for mainline? 2024-07-04 Roger Sayle gcc/ChangeLog PR target/115751 * config/i386/i386-expand.c (ix86_expand_ternlog): Avoid use of force_reg to "reload" non-register operands, as these may contain vec_duplicate (broadcast) operands that aren't supported by force_reg. Use (safer) gen_reg_rtx and emit_move instead. Thanks in advance (sorry for the inconvenience), Roger diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc index dd2c3a8..178dd0b 100644 --- a/gcc/config/i386/i386-expand.cc +++ b/gcc/config/i386/i386-expand.cc @@ -26049,14 +26049,25 @@ ix86_expand_ternlog (machine_mode mode, rtx op0, rtx op1, rtx op2, int idx, break; } - tmp0 = register_operand (op0, mode) ? op0 : force_reg (mode, op0); + if (!register_operand (op0, mode)) + { + /* We can't use force_reg (mode, op0). */ + tmp0 = gen_reg_rtx (GET_MODE (op0)); + emit_move_insn (tmp0,op0); + } + else + tmp0 = op0; if (GET_MODE (tmp0) != mode) tmp0 = gen_lowpart (mode, tmp0); if (!op1 || rtx_equal_p (op0, op1)) tmp1 = copy_rtx (tmp0); else if (!register_operand (op1, mode)) - tmp1 = force_reg (mode, op1); + { + /* We can't use force_reg (mode, op1). */ + tmp1 = gen_reg_rtx (GET_MODE (op1)); + emit_move_insn (tmp1, op1); + } else tmp1 = op1; if (GET_MODE (tmp1) != mode)