From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-sender-0.a4lg.com (mail-sender-0.a4lg.com [IPv6:2401:2500:203:30b:4000:6bfe:4757:0]) by sourceware.org (Postfix) with ESMTPS id 68BAC3858D32 for ; Tue, 5 Sep 2023 05:30:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 68BAC3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=irq.a4lg.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=irq.a4lg.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id 0385B300089; Tue, 5 Sep 2023 05:30:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irq.a4lg.com; s=2017s01; t=1693891807; bh=PZmEFVxZpjFI8EX8U5vO08esT9S7elDycpGZSkcFWRU=; h=Message-ID:Date:Mime-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZPfKUi9wTTTuDz/RiWzcrsjPf4zguEKYqJ3d5IJAv5q92CeB2D3DWnrTivXBpxFpp H0fdDDUcRFis+pvVcG5yy+rtNeyrvH7IstdTtrs/dl7bnGeZYBu81g7oMf+mm2yCIq kkaTy2un56e2sW7eyIxnDw/YlQk33G2l/aU4w02o= Message-ID: <7646998f-126d-43a8-a59e-8ceaad3c2d34@irq.a4lg.com> Date: Tue, 5 Sep 2023 14:30:06 +0900 Mime-Version: 1.0 Subject: Re: [PATCH] RISC-V: Fix Zicond ICE on large constants Content-Language: en-US To: Jeff Law , Kito Cheng Cc: Palmer Dabbelt , Andrew Waterman , Jim Wilson , gcc-patches@gcc.gnu.org References: <3cc5403de383d7c8cfd1769948c2bcf9d54b97f9.1693786829.git.research_trasio@irq.a4lg.com> From: Tsukasa OI In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.5 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 List-Id: On 2023/09/05 14:27, Jeff Law wrote: > > > On 9/4/23 00:45, Kito Cheng wrote: >> Maybe move the check logic a bit forward? My thought is the logic is >> already specialized into a few catalogs, (imm, imm), (imm, reg), (reg, >> reg)... and the logic you put is already in (imm, reg), but it should >> really move into (reg, reg) case IMO? and move that forward we could >> prevent add too much logic to redirect the case. >> >> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc >> index 2db9c81ac8b..c84509c393b 100644 >> --- a/gcc/config/riscv/riscv.cc >> +++ b/gcc/config/riscv/riscv.cc >> @@ -3892,6 +3892,12 @@ riscv_expand_conditional_move (rtx dest, rtx >> op, rtx cons, rtx alt) >>           op1 = XEXP (op, 1); >>         } >> >> +      /* CONS might not fit into a signed 12 bit immediate suitable >> +        for an addi instruction.  If that's the case, force it into >> +        a register.  */ >> +      if (CONST_INT_P (cons) && !SMALL_OPERAND (INTVAL (cons))) >> +       cons = force_reg (mode, cons); >> + >>        /* 0, reg or 0, imm */ >>        if (cons == CONST0_RTX (mode) >>           && (REG_P (alt) > But for the imm, imm case if we force things into regs too early, then > we'll lose if alt - cons and cons fit in a 12 bit immediate but alt does > not. > > I think Tsukasa is on the right path here.  I should have checked > riscv_emit_binary -- I though it handled the out-of-range constant case, > but looking at it now, it clearly does not. > > I think this implies we need a similar blob of code for the imm, imm > case for cons. > > Jeff > Okay, adding a check to "imm, imm" case (although I haven't figured out how to reproduce this case) and will submit the v2. Tsukasa