From patchwork Tue Nov 2 15:17:37 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Maciej W. Rozycki" X-Patchwork-Id: 46957 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0B4013858426 for ; Tue, 2 Nov 2021 15:17:58 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 420683858D35 for ; Tue, 2 Nov 2021 15:17:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 420683858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-wr1-x42c.google.com with SMTP id b12so29424736wrh.4 for ; Tue, 02 Nov 2021 08:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:user-agent:mime-version; bh=47lQhJ7hBTx5PnOYV9GsDrU5G0pn1s+9WH0G+1wClzE=; b=G/+WgDI3X0HNEUZH7A7jT4/mU8NgH6xYYBYedbESW2hHkEKIULr0KLihdFz+BVssEN 6oSACmr5+gYJKiUy6OmhXfJ2URpaE10JVXtYZC9gXY6nXw1eJXp39G5QJAoFQRaMUBXJ rkKnTfLO6e257mH4rW3JEqs/Qa38KBwbXcHq+pWkuaFomWT3iwkzko4hdm+Ms0ZQcg/n XfsJPFvG/GErMttm2peyh5nO90v9g/qde6ykl0xIGOcH8nZ2hKj4FwlxP2O11T0J+WEI jBQwAEuZE133CvdCHWbJ6hd1QPg7ZZc8j5Uax5QVHI6K8H1Ddv4WGvcXgK6caX5SjjgT 8hJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:user-agent :mime-version; bh=47lQhJ7hBTx5PnOYV9GsDrU5G0pn1s+9WH0G+1wClzE=; b=oDZ0+Vf9hgcvyW0O37Jl7zkUQfAAEM/tfzR7+TBBVU+ZAbUMiCqGGIRyQ9aDx8JSaS +/Lk4RoNCwgXNuP8WaFLhZSyxjSKdi7X26QE/R0HZDWtflimwQFyaSKERIRSWTDrCdzI F64qsBPi1MsucTS007TEbf02A8cWNKZ3KuufmnpYd3/Vi41few9GQeof+XKmPiusDLDR khPnGX1xpeBdrZG72LyU2B2LVgMSV3QFKbeJeB3oR3Wbuzx1hZ11OsW6W8V/WHutgTxG +Oai2Zi91wA8Zif51gLcSWCbLZxfGWaNS5y8bhBTKoGsTnLioZzGbM8NtxMjBlghPMBO GgUw== X-Gm-Message-State: AOAM531GnOcJ36GGaAyFYkrTaD9T8KYMMoOj4lFpHag2E0DedH0f4lN8 DjntphvCngQ67LXAQ5pMCZbCT3SADk57Hg== X-Google-Smtp-Source: ABdhPJy/bAFedfgtJzYuW30OvXXJx6RxsVwvBVsyRUDd1bbu2Bq6wpA/4Ea/fYWcJuycGA4IoCMFjA== X-Received: by 2002:a5d:468f:: with SMTP id u15mr33564179wrq.171.1635866259909; Tue, 02 Nov 2021 08:17:39 -0700 (PDT) Received: from [192.168.0.201] ([212.69.42.53]) by smtp.gmail.com with ESMTPSA id h27sm3455369wmc.43.2021.11.02.08.17.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Nov 2021 08:17:39 -0700 (PDT) Date: Tue, 2 Nov 2021 15:17:37 +0000 (GMT) From: "Maciej W. Rozycki" To: gcc-patches@gcc.gnu.org Subject: [PATCH] RISC-V: Fix register class subset checks for CLASS_MAX_NREGS Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: , Cc: Kito Cheng , Andrew Waterman Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Fix the register class subset checks in the determination of the maximum number of consecutive registers needed to hold a value of a given mode. The number depends on whether a register is a general-purpose or a floating-point register, so check whether the register class requested is a subset (argument 1 to `reg_class_subset_p') rather than superset (argument 2) of GR_REGS or FP_REGS class respectively. gcc/ * config/riscv/riscv.c (riscv_class_max_nregs): Swap the arguments to `reg_class_subset_p'. --- Hi, This looks like a thinko to me, but please double-check I have not become confused myself. My understanding is that current code works, because the SIBCALL_REGS and JALR_REGS classes are only ever used for addresses, which won't ever span multiple registers, and then the only class other than ALL_REGS that inludes floating-point registers is FP_REGS. Therefore the hook will only ever see either GR_REGS or FP_REGS as the class enquired about and consequently the result of the `reg_class_subset_p' calls will be the same regardless of the order of the arguments chosen. We should be getting the semantics right regardless. Regression-tested with the `riscv64-linux-gnu' target. OK to apply? Maciej --- gcc/config/riscv/riscv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) gcc-riscv-class-max-nregs.diff Index: gcc/gcc/config/riscv/riscv.c =================================================================== --- gcc.orig/gcc/config/riscv/riscv.c +++ gcc/gcc/config/riscv/riscv.c @@ -4811,10 +4811,10 @@ riscv_modes_tieable_p (machine_mode mode static unsigned char riscv_class_max_nregs (reg_class_t rclass, machine_mode mode) { - if (reg_class_subset_p (FP_REGS, rclass)) + if (reg_class_subset_p (rclass, FP_REGS)) return riscv_hard_regno_nregs (FP_REG_FIRST, mode); - if (reg_class_subset_p (GR_REGS, rclass)) + if (reg_class_subset_p (rclass, GR_REGS)) return riscv_hard_regno_nregs (GP_REG_FIRST, mode); return 0;