From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) by sourceware.org (Postfix) with ESMTPS id 18A7A3858D32 for ; Tue, 5 Sep 2023 05:27:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 18A7A3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oo1-xc2b.google.com with SMTP id 006d021491bc7-5712b68dbc0so1336704eaf.1 for ; Mon, 04 Sep 2023 22:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693891635; x=1694496435; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=a+haI/YHUM8TcZIsLSD5s3rwu1DODuQhQNWKVssIrvU=; b=nu/6Eoqse+CWVTKeJlsfY8yUfScE1ovzOvBdLpdVKpWWv47FyeVTSqwsZ8OpHIhVjO 99HYLYOfmjtThPA5UI4rU+CFBhH4xpqa7hgpfNTTGtptTmxfLfb6pUCvyAl43hmCqfx+ YfDmlLNaBWGrrDq0d3VMIJmegNMd+QXln/tYWs7x86p7bZQYA5n5w81rwE5Od9zsKl6Z 7SYnfYTPoD4AFvme6Jsr86mdvs1frpZKzeGqxPLwFvuR65Irb5q9itsR11JZQikfFEkl 37nGFd1GknTVCxuLcOayxj8qgGeO7AKVBSFuUCVMWb4EZdCH90TbMy3uA/KYV825z6+H jkEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693891635; x=1694496435; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=a+haI/YHUM8TcZIsLSD5s3rwu1DODuQhQNWKVssIrvU=; b=Pg9l2zOskti47PoxRhJ2FwXK39ZTAzmqDO/1xbYCXrxDCirU2HeNCRcEwZPKao23HI AmVFCpydUBBuCXYzF19wztGql7TqDe2RRpbK25R1s9Q0/9Y1kuSftnZs4MTi4eBJAMbE iqGFZCMqSnaW0bSlD7TAwI0adBwm+AI6rlQglqpwS8Ixg8CQ4SYaZE6k/d9aRlrPYgif o7ZlUwsKzzFARVSlQaSLA6E9TYNKcbj9vyM2uVsclT01BQ8Ki5z3xJZz3CCiPQRmQfvd tNkL9hLcwc0yjiNEr9zWHGNytNyYQW4eBjMNo0pdMJdlKVo5+UyTy7Q7c30fu+6ZLzzk PTLA== X-Gm-Message-State: AOJu0Yy3dkVXofpQTHi8BVWBGBxl3NrIy7I8bNohoXlumVVWiOc3NGrW G4mazSM9N7xwW/9qOBvEmzc= X-Google-Smtp-Source: AGHT+IEYtZ+KNVrfam9J8eFoC77ntjTppJd2MRJHGLhOyiJ6XHNeaIROOGyMGvZVtb00ET/uAxX4sg== X-Received: by 2002:a05:6358:8811:b0:134:e41a:9227 with SMTP id hv17-20020a056358881100b00134e41a9227mr13214753rwb.5.1693891635171; Mon, 04 Sep 2023 22:27:15 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id cg11-20020a056a00290b00b0068c9fc82bfbsm7090922pfb.197.2023.09.04.22.27.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Sep 2023 22:27:14 -0700 (PDT) Message-ID: Date: Mon, 4 Sep 2023 23:27:08 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] RISC-V: Fix Zicond ICE on large constants Content-Language: en-US To: Kito Cheng , Tsukasa OI Cc: Palmer Dabbelt , Andrew Waterman , Jim Wilson , gcc-patches@gcc.gnu.org References: <3cc5403de383d7c8cfd1769948c2bcf9d54b97f9.1693786829.git.research_trasio@irq.a4lg.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.4 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 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 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