From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) by sourceware.org (Postfix) with ESMTPS id 878783858C78 for ; Tue, 19 Mar 2024 04:09:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 878783858C78 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 878783858C78 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4860:4864:20::2f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710821350; cv=none; b=qGzAUKXs8ATVqjQYJH1O8GeG+N1A26B3E12xb8ZDY4UOyyIRVeO+1E8WCGzqLX3pJTgPU0iGGmHPsBWXOilOyTJtRsPOszXpa+RSlFc5urPUE/PZk5aiGIgP7mhPe9p/2i+Uy6sdAfGsYFEAypruy58odrDgpj+Rtg4HsU4ZWc4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710821350; c=relaxed/simple; bh=EcZO2kCVsMMreGCw6TO+PkbsXslZSDFBf8FWasEeCy4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=IyQqSoXgu8hg7ywEmMhOrMdU47y2BIvpnBABEU/qaTEzXuWeBR0Govt5lI1RY9ABZpJpW1vEtwYkyIVNjFeXli4lRIxFBs7xIXpmvMnkW5YiSR+tlhYYUPW0Tb0ancuds25MV4Rrr8L9qGXPon6p0TFbXGFlA4YTxoLeFX3eXA4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-222c0572eedso921561fac.3 for ; Mon, 18 Mar 2024 21:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710821347; x=1711426147; 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=i8g7Hx8NzpMxlrViPvxJSpuxEDBIuOA1P6lgMLiKQMc=; b=Cc/idYtdAB+Y0iEf8UNCXohzlh42g4I+W2rjA6EGKS30ObhsFBW3U59y+lCTTButSy 2ngeajErK86yZiOaZGrrERVfbImTFH2upC1cWDIUmdU39aSlhPSMhrP/phIhEoSwinp8 7b/adqW6ixaTgg5KQ60XHezncAec33l68mNbTUdmENz2lJTN8ZCHKLYDT2k8j5gZY0if 1verUCmvPbPYZuSQ/c9MZLdQOrX4QqoX/0zr8E7e9kCav8IKJKl8cJUQl1edBF4Cnrit u+3AEnalNo0C6c0JR+nupUycjsiYYlpAHdzFmwJAdhIZ1vwn0hQob8LFRYxbA43Qxnmw JQKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710821347; x=1711426147; 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=i8g7Hx8NzpMxlrViPvxJSpuxEDBIuOA1P6lgMLiKQMc=; b=ATtEEmRviClE4rSQlSpJcjd8Unpla20rKIW5cdH0J+3ULx+/W/qb5J4OdCTw038sqe jXqblegmclHJwzIw094kJEVhA/j1GRy+5ShUuW7SgvjoUGXC6yWvUECX0dEMT6ulfUfa NwPru4AreQVGMs8qa2H9GLEQPu7f+eSRNKq3mZAtDHqofCdz6U9ovRxZs+eT+JQYbD9P TPnh0R1tJ3DsHuML/cAPnznOK782/8MLpWqK66Cz1Yg2/57/jByPnWOesXR7R9muXm1A ix5o5ccC8o2G71JCTLpJcAKhP295OsijKVn572m58Igt6Pv9sbFiMrMXDosun6n6XV7D 3sJA== X-Gm-Message-State: AOJu0YwEjMGMCt8gwS5PjlL5Hl0RHB/A6x4FtKevI/7dkQxDQ3EIsFgQ Sc38aUbCIZuj6sg1yWPU4lw+881AbyRB0fuliWdBY9xIm2U7hkON X-Google-Smtp-Source: AGHT+IF16lmiR6PFeGEDexTkmOL0WdGcy0lTggX1dIpd8petKt9xbi0pYP0dM69kfd8VlMNi8eKm4g== X-Received: by 2002:a05:6871:5c46:b0:221:f921:4672 with SMTP id os6-20020a0568715c4600b00221f9214672mr1707360oac.14.1710821347184; Mon, 18 Mar 2024 21:09:07 -0700 (PDT) Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id nw5-20020a056870bb0500b00220c6f7734esm2918174oab.35.2024.03.18.21.09.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Mar 2024 21:09:06 -0700 (PDT) Message-ID: <9c4e07e8-0913-45a9-a717-00f9469e11ca@gmail.com> Date: Mon, 18 Mar 2024 22:09:05 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH] RISC-V: Allow LICM hoist POLY_INT configuration code sequence Content-Language: en-US To: Robin Dapp , "juzhe.zhong@rivai.ai" , "kito.cheng" Cc: gcc-patches , "Kito.cheng" References: <20240201154550.316746-1-juzhe.zhong@rivai.ai> <4AF20724FCB5A950+202402041003488289149@rivai.ai> <56e4737a-0e63-4110-886f-0d8d2c764e29@gmail.com> From: Jeff Law In-Reply-To: <56e4737a-0e63-4110-886f-0d8d2c764e29@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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,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 List-Id: On 2/6/24 6:14 AM, Robin Dapp wrote: >> The root cause is this following RTL pattern, after fwprop1: >> >> (insn 82 78 84 9 (set (reg:DI 230) >>         (sign_extend:DI (minus:SI (subreg/s/v:SI (reg:DI 150 [ niters.10 ]) 0) >>                 (subreg:SI (reg:DI 221) 0)))) 13 {subsi3_extended} >>      (expr_list:REG_EQUAL (sign_extend:DI (plus:SI (subreg/s/v:SI (reg:DI 150 [ niters.10 ]) 0) >>                 *(const_poly_int:SI [-16, -16])*)) >>         (nil))) >> >> The highlight *(const_poly_int:SI [-16, -16])* >> causes ICE. >> >> This RTL is because: >> (insn 69 68 71 8 (set (reg:DI 221) >>         (const_poly_int:DI [16, 16])) 208 {*movdi_64bit} >>      (nil)) >> (insn 82 78 84 9 (set (reg:DI 230) >>         (sign_extend:DI (minus:SI (subreg/s/v:SI (reg:DI 150 [ niters.10 ]) 0) >>                 (subreg:SI (reg:DI 221) 0)))) 13 {subsi3_extended}                                          ----> (subreg:SI (const_poly_int:SI [-16, -16])) fwprop1 add  (const_poly_int:SI [-16, -16]) reg_equal >>      (expr_list:REG_EQUAL (sign_extend:DI (plus:SI (subreg/s/v:SI (reg:DI 150 [ niters.10 ]) 0) >>                 (const_poly_int:SI [-16, -16]))) >>         (nil))) > > I'm seeing a slightly different pattern but that doesn't change > the problem. > >> (set (reg:SI) (subreg:SI (DI: poly value))) but it causes ICE that I >> mentioned above. > > That's indeed a bit more idiomatic and I wouldn't oppose that. > > The problem causing the ICE is that we want to simplify a PLUS > with (const_poly_int:SI [16, 16]) and (const_int 0) but the mode > is DImode. My suspicion is that this is caused by our > addsi3_extended pattern and we fail to deduce the proper mode > for analysis. Certainly possible. It didn't even occur to me that a POLY_INT would slip through here. > > I'm just speculating but maybe that's because we assert that a > plus is of the form simple_reg_p (op0) && CONSTANT_P (op1). > Usually, constants don't have a mode and can just be used. > poly_int_csts do have one and need to be explicitly converted > (kind of). > > We can only analyze this zero_extended plus at all since Jeff > added the addsi3_extended handling for loop-iv. Maybe we could > punt like > > diff --git a/gcc/loop-iv.cc b/gcc/loop-iv.cc > index eb7e923a38b..796413c25a3 100644 > --- a/gcc/loop-iv.cc > +++ b/gcc/loop-iv.cc > @@ -714,6 +714,9 @@ get_biv_step_1 (df_ref def, scalar_int_mode outer_mode, rtx reg, > if (!simple_reg_p (op0) || !CONSTANT_P (op1)) > return false; > > + if (CONST_POLY_INT_P (op1) && GET_MODE (op1) != outer_mode) > + return false; > + > > This helps for your test case but I haven't done any further > testing. I'd think this is relatively safe because it's only > a missed analysis/optimization in the worst case. > Still, generally, I don't see a reason why we wouldn't be able > to analyze this? I don't think it would significant hurt anything. IIRC bit of code was to fix a minor regression caused by the backend changes. I would ACK that patch given the usual testing cycle. jeff