From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 104A73858C33; Tue,  5 Mar 2024 09:54:25 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 104A73858C33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1709632466;
	bh=s4T8+GkQX4iAWS5smEIQrJpPMuhAtOFlXQnq/zDFld0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=TOU2y4EqCWfjBhFdk/lmx2PxrNR0PLvy0IbE/da3yCtViqOLj9O6PdneEiI97E28Y
	 mY7scEiX0nR+Pd71dXursfg9WW0Bpx0z6W+G8FULb2W0/kr0c6UPtsm6DRPPtMUmSR
	 bRrMw0QcxRmSREbBQO9C4lwZbAuAHc/jjXePrNIA=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/114231] [12/13/14 regression] ICE when
 building libjxl
Date: Tue, 05 Mar 2024 09:54:24 +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: 14.0
X-Bugzilla-Keywords: ice-on-valid-code, needs-bisection
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114231-4-DluYzKrGp3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114231-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114231-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114231

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the immediate reason is that between analysis and transform whether we
consider the shift vectorizable changes.  That's because we code generated
a live lane which ended up changing operands in stmts we will vectorize
(there's some odd broken handling there I think).  That's because we
match up the scalar from the SLP node with the scalar in the scalar GIMPLE
IL (which changed) here:

  stmt_vec_info op1_def_stmt_info;
  slp_tree slp_op1;
  if (!vect_is_simple_use (vinfo, stmt_info, slp_node, 1, &op1, &slp_op1,
                           &dt[1], &op1_vectype, &op1_def_stmt_info))
...
          FOR_EACH_VEC_ELT (stmts, k, slpstmt_info)
            {
              gassign *slpstmt =3D as_a <gassign *> (slpstmt_info->stmt);
              if (!operand_equal_p (gimple_assign_rhs2 (slpstmt), op1, 0))
                scalar_shift_arg =3D false;
            }=20

which is a bit fragile.

But the underlying issue seems to be the live lane stuff.

Ah, and that's because we do the reduction discovery on the original
scalar stmt while live lane extraction honors patterns when checking
whether the stmt is vectorized ...

I have a patch, not sure how big the fallout might be though.=