From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D2A233858C27; Thu, 14 Sep 2023 06:46:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D2A233858C27 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1694673973; bh=zgY3R03e5bYGzg74EWq4rGq4BWpe2b6sk+JVbr8eylI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=B+kOT2kOEnszN1fPgBrVYkLrpiq0lGYqsbrRkNwDtFFwfja3Zqa1aX5s0w/A9Nutc HG3SJ3cWaNVYKaIO3vNyOR1agYu34QsCehedvtM2gA/ggV2hprD/qrvS9IjD1zmcTv 9KE8ZRf1Gmh2gRYZQeg6winwdD25kgvIJdRlvlMQ= From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/111401] Middle-end: Missed optimization of MASK_LEN_FOLD_LEFT_PLUS Date: Thu, 14 Sep 2023 06:46:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de 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=3D111401 --- Comment #4 from rguenther at suse dot de --- On Wed, 13 Sep 2023, rdapp at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111401 >=20 > Robin Dapp changed: >=20 > What |Removed |Added > -------------------------------------------------------------------------= --- > CC| |rdapp at gcc dot gnu.org >=20 > --- Comment #2 from Robin Dapp --- > I played around with this a bit. Emitting a COND_LEN in if-convert is ea= sy: >=20 > _ifc__35 =3D .COND_ADD (_23, init_20, _8, init_20); >=20 > However, during reduction handling we rely on the reduction being a gimple > assign and binary operation, though so I needed to fix some places and in= dices > as well as the proper mask. >=20 > What complicates things a bit is that we assume that "init_20" (i.e. the > reduction def) occurs once when we have it twice in the COND_ADD. I just > special cased that for now. Is this the proper thing to do? I think so - we should ignore a use in the else value when the other use is in that same stmt. > diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc > index 23c6e8259e7..e99add3cf16 100644 > --- a/gcc/tree-vect-loop.cc > +++ b/gcc/tree-vect-loop.cc > @@ -3672,7 +3672,7 @@ vect_analyze_loop (class loop *loop, vec_info_shared > *shared) > static bool > fold_left_reduction_fn (code_helper code, internal_fn *reduc_fn) > { > - if (code =3D=3D PLUS_EXPR) > + if (code =3D=3D PLUS_EXPR || code =3D=3D IFN_COND_ADD) > { > *reduc_fn =3D IFN_FOLD_LEFT_PLUS; > return true; > @@ -4106,8 +4106,11 @@ vect_is_simple_reduction (loop_vec_info loop_info, > stmt_vec_info phi_info, > return NULL; > } >=20 > - nphi_def_loop_uses++; > - phi_use_stmt =3D use_stmt; > + if (use_stmt !=3D phi_use_stmt) > + { > + nphi_def_loop_uses++; > + phi_use_stmt =3D use_stmt; > + } >=20 > @@ -7440,6 +7457,9 @@ vectorizable_reduction (loop_vec_info loop_vinfo, > if (i =3D=3D STMT_VINFO_REDUC_IDX (stmt_info)) > continue; >=20 > + if (op.ops[i] =3D=3D op.ops[STMT_VINFO_REDUC_IDX (stmt_info)]) > + continue; > + >=20 > Apart from that I think what's mainly missing is making the added code ni= cer.=20 > Going to attach a tentative patch later. >=20 >=