From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3D5563857C5A; Thu, 5 Oct 2023 07:48:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3D5563857C5A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1696492091; bh=2/zojFQZXMWGnqgs6V1GVv+q71fK294DZYm7/C6Dy6E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cxErGWal+HTh3eJLXScD4EyR18uo152PytRKyY6n6f58rzdZATgGHiytehhV/LWMY HR8Lo95hSMYIkwPmzJ7TwnAmtaz5i5RfBKx9skYVjfVWotlMbl95DeqZ93LkIn7NNe NwvwH1FnP7h37alQjcVIcsL3CXFsZwaI9avW+B2k= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/111697] Sub optimal code gen for initialising vector using loop Date: Thu, 05 Oct 2023 07:48:10 +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: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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=3D111697 --- Comment #3 from Richard Biener --- (In reply to Richard Biener from comment #2) > We have quite some code doing vector CTOR stuff in tree-ssa-forwprop.cc a= nd > this should be optimized to >=20 > v_2 =3D { x_6(D), x_6(D), x_6(D), x_6(D) }; >=20 > note SLP vectorization can do this but it fails because it doesn't handle > a default def insert - it handles a group of BIT_INSERT_EXPRs as > vector CTOR and SLP discovery doesn't know how to start from external defs > (it needs actual definition stmts). >=20 > A more general approach would be to try to track vector construction thro= ugh > symbolic execution like we form bswap in the bswap pass. You could "steal" the code in vect_slp_check_for_roots, else if (code =3D=3D BIT_INSERT_EXPR && VECTOR_TYPE_P (TREE_TYPE (rhs)) && TYPE_VECTOR_SUBPARTS (TREE_TYPE (rhs)).is_constant () && TYPE_VECTOR_SUBPARTS (TREE_TYPE (rhs)).to_constant () > 1 && integer_zerop (gimple_assign_rhs3 (assign)) && useless_type_conversion_p (TREE_TYPE (TREE_TYPE (rhs)), TREE_TYPE (gimple_assign_rhs2 (assign))) && bb_vinfo->lookup_def (gimple_assign_rhs2 (assign))) { /* We start to match on insert to lane zero but since the inserts need not be ordered we'd have to search both the def and the use chains. */ ... and put it into tree-ssa-forwprop.cc, explicitly creating the vector CTOR.=