From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 9C7723858D37 for ; Tue, 6 Feb 2024 13:14:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C7723858D37 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 9C7723858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::630 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707225252; cv=none; b=Mh3jqIQRQQvfp6pl6DGkGgyq6J5WqcBVVHNk73RvYnpCv9UL99QfPOw1t0pRrWVuKB21GZ4k+SlCx/flp0rNbNX18nCHB9bNoVvsl9NEr8+QdU6vkWkERTKr+hKNYUq22+M9XA2q5Xf2Itys7VZVfVZIHagqGGdcw4fQ4PyhwWE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707225252; c=relaxed/simple; bh=PEZ5szq+6OgVOpZSnaSiJPrqLg0EK8gUXLdOmBRE7PY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=xJCwJG17hBCP5anTSlV7K9K+uskkQcmP17kp2WZJn6exPwg5vuCHIGzo/MPr7EThF1L38Ek/vUC2Vd2bkTQVY+4Ty2slv40VYB8ECfUNMgdByCko5IphPEowoYNcjguWpfDvqv3Tgn8kve5cWNee24esoL3kvnCgcQdKVTvc/Mc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a380a1fa56fso106103366b.0 for ; Tue, 06 Feb 2024 05:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707225249; x=1707830049; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=d+f17nnyl/6uGnhFElumMdhbRMAtXzouL6UOgRUtnNQ=; b=b7lN5QowtVrO/gCGG9o4F/XVj/w05ZVgANVEKIaWZHDUB7B/bb67gQUzvRtpCukc8t FaMXfpSDdEfO0219H0EMnR8+rJr0ZVXcuwQU3YT6TGeHBdHPGCXsI2VoZlAlZCI/mGwh 0MCAT7XBtuKB+qWWsZTsGcw/3A+pTudm9kkQr3BblNWQq749FQhpCkTa2IWjG2yE6q2k Kr6MTY06WzfrhfECMex4Cfwmb9pPoiprtRVL7cbHQP4ml2NjkD+M8m6eErei3cuFPkn7 OmavtN3duG7qhy76vTNn+gblr50YEmPz2ORbUO4Q87NMbSvvGNIRgEe7/NI21RUAmOG1 0+Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707225249; x=1707830049; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=d+f17nnyl/6uGnhFElumMdhbRMAtXzouL6UOgRUtnNQ=; b=ZD2WM97FN+3ukzp4MrCo2QBkXEg9WuQro2gk0w7OgS4Mtxo9fcACqezzRlDyxRsK84 6x4H2jgMoOrRyEgw25Q43+i/dzNsYw7ydWiUng3QUZSLaom4BOeXSaNuvfxKjJ2z7GBm D4USrwVJ4eSTYnlrWDhoZ8E7FfyXmmsT+579CBlmVRtw9vD8d3RPDEzRhQwO+//VOhaP dcjtaorGUtgVGM9RK8W0Gdt88/QXuuPxhrNNQ5s7+H2/bP7ySu/8hGvGmVfd6SlsMHhy hz1DhoB+127x9oMFTZY/l1AdSUkWuxuPQ0mkMUDI1Az9o/cpmb29vGm8woCHsWNFaEFV KXsw== X-Gm-Message-State: AOJu0Yxs3wRIKAZ0rvHVbgL0nHpIGufdkAePpNTgoYAbX/a7GlMzW6/E mo2ewPUiAwFrn1OjkU9gupEoo0XNCsztkMa3teu7hQPYG8Vj/bgU X-Google-Smtp-Source: AGHT+IHL0nP/fPEtRdvCfC57S7kwekT2PrgWUlMpIUc9hjUhhPh1vN1ATZ563gDAp7wcMhTGEfesZg== X-Received: by 2002:a17:906:ad3:b0:a38:4822:9991 with SMTP id z19-20020a1709060ad300b00a3848229991mr473162ejf.35.1707225249043; Tue, 06 Feb 2024 05:14:09 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCWsJWwJY8bpG/urGPFVwJc80y9Epl0fsPkHHyOiokCyBh8SXEHfwK0isTLcIlXlnYgEtgS3JQikGRM1wZBGgJ6Z1fW2fN4VgdzUryG6WERKCVqga5U2XdzyvpAY1rQ9nWdsbeiPBAtthffKXIcNg3DRdbn62INy1PRX22MK43WjmNl2avSO1KFiJrTa Received: from [192.168.1.23] (ip-149-172-150-237.um42.pools.vodafone-ip.de. [149.172.150.237]) by smtp.gmail.com with ESMTPSA id hw17-20020a170907a0d100b00a37319aadb0sm1145859ejc.15.2024.02.06.05.14.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Feb 2024 05:14:08 -0800 (PST) Message-ID: <56e4737a-0e63-4110-886f-0d8d2c764e29@gmail.com> Date: Tue, 6 Feb 2024 14:14:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: rdapp.gcc@gmail.com, gcc-patches , "Kito.cheng" , jeffreyalaw Subject: Re: [PATCH] RISC-V: Allow LICM hoist POLY_INT configuration code sequence Content-Language: en-US To: "juzhe.zhong@rivai.ai" , "kito.cheng" References: <20240201154550.316746-1-juzhe.zhong@rivai.ai> <4AF20724FCB5A950+202402041003488289149@rivai.ai> From: Robin Dapp In-Reply-To: <4AF20724FCB5A950+202402041003488289149@rivai.ai> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.9 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: > 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. 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? Regards Robin