From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 4314E3858D35 for ; Tue, 23 May 2023 12:27:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4314E3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0B472139F; Tue, 23 May 2023 05:28:06 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4EB9E3F6C4; Tue, 23 May 2023 05:27:20 -0700 (PDT) From: Richard Sandiford To: Jeff Law via Gcc-patches Mail-Followup-To: Jeff Law via Gcc-patches ,Jin Ma , Jeff Law , jinma.contrib@gmail.com, richard.sandiford@arm.com Cc: Jin Ma , Jeff Law , jinma.contrib@gmail.com Subject: Re: [PATCH] Fix type error of 'switch (SUBREG_BYTE (op)).' References: <20230517090315.795-1-jinma@linux.alibaba.com> Date: Tue, 23 May 2023 13:27:19 +0100 In-Reply-To: (Jeff Law via Gcc-patches's message of "Wed, 17 May 2023 15:49:31 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-22.8 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Jeff Law via Gcc-patches writes: > On 5/17/23 03:03, Jin Ma wrote: >> For example: >> (define_insn "mov_lowpart_sidi2" >> [(set (match_operand:SI 0 "register_operand" "=r") >> (subreg:SI (match_operand:DI 1 "register_operand" " r") 0))] >> "TARGET_64BIT" >> "mov\t%0,%1") >> >> (define_insn "mov_highpart_sidi2" >> [(set (match_operand:SI 0 "register_operand" "=r") >> (subreg:SI (match_operand:DI 1 "register_operand" " r") 1))] >> "TARGET_64BIT" >> "movh\t%0,%1") >> >> When defining the above patterns, the generated file insn-recog.cc will >> appear 'switch (SUBREG_BYTE (op))', but since the return value of >> SUBREG_BYTE is poly_uint16_pod, the following error will occur: >> "error: switch quantity not an integer". >> >> gcc/ChangeLog: >> >> * genrecog.cc (print_nonbool_test): Fix type error of >> 'switch (SUBREG_BYTE (op))'. > Thanks. Installed. We shouldn't add to_constant just because it's a convenient way of getting rid of errors :) There has to be a good reason in principle why the value is known at compile time. So I think this should be reverted. Nothing guarantees that SUBREG_BYTEs are constant on AArch64 and RISC-V. And for SVE it's common for them not to be. If we want to support the above, I think we need to make the generator use known_eq instead. The patterns don't look right though. An SI subreg of a DI can't have a SUBREG_BYTE of 1. And the lowpart SUBREG_BYTE depends on endianness. So I think a better way of writing the lowpart pattern above is to use subreg_lowpart_operator (which riscv already has). The high part can't be done using subregs though. Thanks, Richard