From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 247E43858421; Mon, 6 Feb 2023 11:55:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 247E43858421 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1675684559; bh=iN6g3k1p03jyrcxXZn3dtnuQvuZnX4GIHuCxYpLhLr8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AQMHtBvNRJrr1/IDgauE+OWo1tukdTRVUFt/EEXK/pdDL100ShjnW5EJ+rQbtiUVt ZX7IG2cDyPJh0B3p/sDIQGrJfBG7uwtQ2mSj+R3fLE+Bdfxq60FzkYEHlybZ4MQM0i 6Vv/MCJp4QmrGxoFv6k4+NlcCTPoBGPfTFntTe/M= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/106433] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032 Date: Mon, 06 Feb 2023 11:55:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: ice-on-valid-code, openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106433 --- Comment #4 from Jakub Jelinek --- Created attachment 54413 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D54413&action=3Dedit gcc13-pr106433.patch Seems in this case the set_const_call happens far later, during the local-pure-const2 pass very soon before expansion into RTL. The simd clones are created during late IPA, but the cgraph ordering in this case is that bar is optimized + expanded first, then its caller foo, then t= he simd clones of foo and finally the simd clones of bar. In order to be able= to DCE unneeded simd clones, that is the intended ordering that we process simd clones only after processing their (possible) callers, so that if we decide= not to use them and they are static, they can go away. The big question is if it is safe to make those clones const or pure if the function they are cloned from is. I'd hope it is, they are created by the compiler from the functions they were cloned from and they should be just possibly vectorized versions thereof handling more than one argument concurrently. I can imagine we'd be able to determine during optimizations= one is const and couldn't prove it for the other, but I'd say if it is safe for= one version it ought to be safe for another one too.=