From patchwork Sun Nov 19 19:00:15 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 1865786 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=icuWlzky; 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 4SYKhz4R99z1yS4 for ; Mon, 20 Nov 2023 06:00:35 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E7632383D7A9 for ; Sun, 19 Nov 2023 19:00:32 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) by sourceware.org (Postfix) with ESMTPS id CA94A383D7A9 for ; Sun, 19 Nov 2023 19:00:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CA94A383D7A9 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CA94A383D7A9 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::329 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700420422; cv=none; b=l5opWKxpKLfmgzVzSF8J2yWyfgUPLjPuuMWXmtOwA2ullf8w9/RAi3cfeLy9hXrShja0NVN7FC+pxG6suFW3Hhzf5+03KAWUPYDUOdkxexCDCaaR5sKgCdQ6QxnRErdrweR0t0pbDH11LEfA7loKgNORX8cTHWhiAVelSs+lUDA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700420422; c=relaxed/simple; bh=5lHhXZSkYGa4dCOA8hyzkeUlSif/RmdRnfEpE32s/VA=; h=DKIM-Signature:Message-ID:Date:MIME-Version:From:Subject:To; b=bPAGIzRPk3MkCMqRT76W4ppwQd+6p60MHB+GrPzCkKjleQ5ocT4p8bGTvLCaiTWNElEY5MtFAsczbDRDIHZ31phE54KmqsjyCbLgFkcySK4EXn2OmiRZaDf8XUC1vWgiUSBgvuSpuxd8EWMvkV3+g7TDMDpOCosS9ZaU8LaiqcI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ot1-x329.google.com with SMTP id 46e09a7af769-6ce37683cf6so2268945a34.3 for ; Sun, 19 Nov 2023 11:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700420417; x=1701025217; darn=gcc.gnu.org; h=to:subject:from:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=TSZcT8QHLYIdjtaFJOZt79LRcoMnFuM9/CO0eyprYUU=; b=icuWlzkyAkIWFxlNkXfACaS9xaJVmWfYC9lw/BruYTH6gBcOindymcPcWiXLhVFQ/s h20WIfYgYLUMyTG8SXEEpO2EhdFga9VqDkdtDP84azD93Yj79pIZmRl2ri9Z9B45LNoW HJ/WzjLmZ84mX26tZ4cjvJs8GG86bUVLurbL80YBpkDH/4lrm7hzM+bbXYHKhtQgJgPc bkKI4h9z63lb0+JOkbGPDT175Mx06JudeopBWxu2bYvKJqvGDvEWxhobRXJi3cXNA0Dy aUQO3utXFZ0qS/rfPgDIvqqoQDIF0SUuA5sgWKmLrNRuo5TT+xW5C9odtdAg7I4jlqT4 EDUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700420417; x=1701025217; h=to:subject:from:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TSZcT8QHLYIdjtaFJOZt79LRcoMnFuM9/CO0eyprYUU=; b=Z/lUCQImpxhZHf+bvq/UKBim1RkgtRA12VukVZaVtQH03KgdKBC0M6RV9DK3dpAsVY WA0WA08LOKAzLnSpqyV4CIu5sCoO5+Guub1n2VkMuMml3+OPz66MU8sCuyg6NVYUZi6q 2KunA1Z4LqMqHg5xPGX8iQkhDXTPGxpsJ9R9SDWVOK/V8TfMczmcT4j2MrclQCBQOYsG mNKNK64QkmcVMPpe74UpYTbcNx7h34aJuinuT2KX/3zl2KDdgX/D0peuzfQ3+ZQhh+H6 CuPQ+V615sYnWdcFjVIMGUAtVfVBFbBJht5D8K79mtOFHEo6OIAzF415vgrFZCnLfgBd p4GA== X-Gm-Message-State: AOJu0Yyit5cozR6tw972FN5c0PERrIMDUyMMKqznApT/OEJ6Fe8FbUXW UhAX4pWRgf9d5Z8QA4xNFwR1F1fxTqjyhg== X-Google-Smtp-Source: AGHT+IFldvSdwq88FEONJWtTnRN4cbA02Y/LEIpohTl8e+Y9e3lAA6AQeLikCF0OHkopusVBx/6hXQ== X-Received: by 2002:a05:6830:44a2:b0:6d6:4f73:dbf4 with SMTP id r34-20020a05683044a200b006d64f73dbf4mr6552811otv.24.1700420417318; Sun, 19 Nov 2023 11:00:17 -0800 (PST) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id ay2-20020a056830468200b006cd0a56c406sm944912otb.60.2023.11.19.11.00.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Nov 2023 11:00:16 -0800 (PST) Message-ID: Date: Sun, 19 Nov 2023 12:00:15 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Jeff Law Subject: [committed] Fix missing mode on a few unspec/unspec_volatile operands To: "gcc-patches@gcc.gnu.org" X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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 is fix for a minor problem Jivan and I found while testing the ext-dce work originally from Joern. The ext-dce pass will transform zero/sign extensions into subreg accesses when the upper bits are actually unused. So it's more likely with the ext-dce work to get a sequence like this prior to combine: > >> (insn 10 9 11 2 (set (reg:SI 144) >> (unspec_volatile [ >> (const_int 0 [0]) >> ] UNSPECV_FRFLAGS)) "j.c":11:3 discrim 1 362 {riscv_frflags} >> (nil)) >> (insn 11 10 55 2 (set (reg:DI 140 [ _12 ]) >> (subreg:DI (reg:SI 144) 0)) "j.c":11:3 discrim 1 206 {*movdi_64bit} >> (expr_list:REG_DEAD (reg:SI 144) >> (nil))) When we try to combine insn 10->11 we'll ultimately call simplify_subreg with something like (subreg:DI (unspec_volatile [...]) 0) Note the lack of a mode on the unspec_volatile. That in turn will cause simplify_subreg to trigger an assertion. The modeless unspec is generated by the RISC-V backend and the more I've pondered this issue over the last few days the more I'm convinced it's a backend bug. Basically if the LHS of the set has a mode, then the RHS of the set should have a mode as well. I've audited the various backends and only found a few problems which are fixed by this patch. I've tested the relevant ports in my tester. c6x, sh, mips and s390[x]. There are other patterns that are potentially problematical in various ports. They have a REG destination and an UNSPEC source, but the REG has no mode in the pattern. Since it wasn't clear what mode to give the UNSPEC, I left those alone. Pushing to the trunk. jeff commit 07da9b7f13c92a21d12172a9df85ad762591b998 Author: Jeff Law Date: Sun Nov 19 11:56:57 2023 -0700 [committed] Fix missing mode on a few unspec/unspec_volatile operands This is fix for a minor problem Jivan and I found while testing the ext-dce work originally from Joern. The ext-dce pass will transform zero/sign extensions into subreg accesses when the upper bits are actually unused. So it's more likely with the ext-dce work to get a sequence like this prior to combine: > >> (insn 10 9 11 2 (set (reg:SI 144) >> (unspec_volatile [ >> (const_int 0 [0]) >> ] UNSPECV_FRFLAGS)) "j.c":11:3 discrim 1 362 {riscv_frflags} >> (nil)) >> (insn 11 10 55 2 (set (reg:DI 140 [ _12 ]) >> (subreg:DI (reg:SI 144) 0)) "j.c":11:3 discrim 1 206 {*movdi_64bit} >> (expr_list:REG_DEAD (reg:SI 144) >> (nil))) When we try to combine insn 10->11 we'll ultimately call simplify_subreg with something like (subreg:DI (unspec_volatile [...]) 0) Note the lack of a mode on the unspec_volatile. That in turn will cause simplify_subreg to trigger an assertion. The modeless unspec is generated by the RISC-V backend and the more I've pondered this issue over the last few days the more I'm convinced it's a backend bug. Basically if the LHS of the set has a mode, then the RHS of the set should have a mode as well. I've audited the various backends and only found a few problems which are fixed by this patch. I've tested the relevant ports in my tester. c6x, sh, mips and s390[x]. There are other patterns that are potentially problematical in various ports. They have a REG destination and an UNSPEC source, but the REG has no mode in the pattern. Since it wasn't clear what mode to give the UNSPEC, I left those alone. gcc/ * config/c6x/c6x.md (mvilc): Add mode to UNSPEC source. * config/mips/mips.md (rdhwr_synci_step_): Likewise. * config/riscv/riscv.md (riscv_frcsr, riscv_frflags): Likewise. * config/s390/s390.md (@split_stack_call): Likewise. (@split_stack_cond_call): Likewise. * config/sh/sh.md (sp_switch_1): Likewise. diff --git a/gcc/config/c6x/c6x.md b/gcc/config/c6x/c6x.md index 88b9291ae23..906fdb34a82 100644 --- a/gcc/config/c6x/c6x.md +++ b/gcc/config/c6x/c6x.md @@ -1440,7 +1440,7 @@ (define_expand "doloop_end" (define_insn "mvilc" [(set (reg:SI REG_ILC) - (unspec [(match_operand:SI 0 "register_operand" "a,b")] UNSPEC_MVILC))] + (unspec:SI [(match_operand:SI 0 "register_operand" "a,b")] UNSPEC_MVILC))] "TARGET_INSNS_64PLUS" "%|%.\\tmvc\\t%$\\t%0, ILC" [(set_attr "predicable" "no") diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md index a25454783fb..0666310734e 100644 --- a/gcc/config/mips/mips.md +++ b/gcc/config/mips/mips.md @@ -5732,7 +5732,7 @@ (define_insn "synci" (define_insn "rdhwr_synci_step_" [(set (match_operand:P 0 "register_operand" "=d") - (unspec_volatile [(const_int 1)] + (unspec_volatile:P [(const_int 1)] UNSPEC_RDHWR))] "ISA_HAS_SYNCI" "rdhwr\t%0,$1") diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md index 8f28e8e56ab..1522b0b27cc 100644 --- a/gcc/config/riscv/riscv.md +++ b/gcc/config/riscv/riscv.md @@ -3301,7 +3301,7 @@ (define_insn "gpr_restore_return" (define_insn "riscv_frcsr" [(set (match_operand:SI 0 "register_operand" "=r") - (unspec_volatile [(const_int 0)] UNSPECV_FRCSR))] + (unspec_volatile:SI [(const_int 0)] UNSPECV_FRCSR))] "TARGET_HARD_FLOAT || TARGET_ZFINX" "frcsr\t%0" [(set_attr "type" "fmove")]) @@ -3314,7 +3314,7 @@ (define_insn "riscv_fscsr" (define_insn "riscv_frflags" [(set (match_operand:SI 0 "register_operand" "=r") - (unspec_volatile [(const_int 0)] UNSPECV_FRFLAGS))] + (unspec_volatile:SI [(const_int 0)] UNSPECV_FRFLAGS))] "TARGET_HARD_FLOAT || TARGET_ZFINX" "frflags\t%0" [(set_attr "type" "fmove")]) diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md index 4bdb679daf2..bc740a70015 100644 --- a/gcc/config/s390/s390.md +++ b/gcc/config/s390/s390.md @@ -12252,9 +12252,9 @@ (define_expand "split_stack_space_check" (define_insn "@split_stack_call" [(set (pc) (label_ref (match_operand 2 "" ""))) ; call done label - (set (reg:P 1) (unspec_volatile [(match_operand 0 "bras_sym_operand" "X") - (reg:P 1)] - UNSPECV_SPLIT_STACK_CALL)) + (set (reg:P 1) (unspec_volatile:P [(match_operand 0 "bras_sym_operand" "X") + (reg:P 1)] + UNSPECV_SPLIT_STACK_CALL)) (use (label_ref (match_operand 1 "" "X"))) ; parm block label (use (match_operand 3 "const_int_operand" "X")) ; frame size (use (match_operand 4 "const_int_operand" "X"))] ; arg size @@ -12274,9 +12274,9 @@ (define_insn "@split_stack_cond_call" (match_operand 5 "" "") ; condition (label_ref (match_operand 2 "" "")) ; call done label (pc))) - (set (reg:P 1) (unspec_volatile [(match_operand 0 "bras_sym_operand" "X") - (reg:P 1)] - UNSPECV_SPLIT_STACK_CALL)) + (set (reg:P 1) (unspec_volatile:P [(match_operand 0 "bras_sym_operand" "X") + (reg:P 1)] + UNSPECV_SPLIT_STACK_CALL)) (use (label_ref (match_operand 1 "" "X"))) ; parm block label (use (match_operand 3 "const_int_operand" "X")) ; frame size (use (match_operand 4 "const_int_operand" "X"))] ; arg size diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md index 193f40d4419..8321d9fa121 100644 --- a/gcc/config/sh/sh.md +++ b/gcc/config/sh/sh.md @@ -10936,7 +10936,7 @@ (define_peephole ;; Switch to a new stack with its address in sp_switch (a SYMBOL_REF). (define_insn "sp_switch_1" - [(set (reg:SI SP_REG) (unspec_volatile [(match_operand:SI 0 "" "")] + [(set (reg:SI SP_REG) (unspec_volatile:SI [(match_operand:SI 0 "" "")] UNSPECV_SP_SWITCH_B))] "TARGET_SH1" {