From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BFDDE3857B83; Tue, 28 Nov 2023 10:55:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BFDDE3857B83 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1701168926; bh=1/UIOlVtrwDbf/dIgBkEgC7rH1YXpXM7abLo80hakhA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=rC+uO01IiWhBa0h7+P25i+0oCpKyB4N7pr7i0D7kga1Ro/2gVPIPnJi0dwWapHdlJ zAZ9lsxG1oiG4EdL+oH0eQmTSZQqON4PhtObaOlfem/soXUJydYHuS3zQwP+Z6tGTN CL9ssmAT4HdZPqmyZYe9BX7HdMSHub3k/Ows0/BY= From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/52252] An opportunity for x86 gcc vectorizer (gain up to 3 times) Date: Tue, 28 Nov 2023 10:55: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: 4.7.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement 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=3D52252 --- Comment #11 from rguenther at suse dot de --- On Tue, 28 Nov 2023, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D52252 >=20 > Andrew Pinski changed: >=20 > What |Removed |Added > -------------------------------------------------------------------------= --- > CC| |pinskia at gcc dot gnu.o= rg >=20 > --- Comment #10 from Andrew Pinski --- > Note there is also a missing scalar optimization here also (which will im= prove > the vectorized version in the end too). >=20 > Right now we have the following match pattern: > /* MIN (~X, ~Y) -> ~MAX (X, Y) > MAX (~X, ~Y) -> ~MIN (X, Y) */ > (for minmax (min max) > maxmin (max min) > (simplify > (minmax (bit_not:s@2 @0) (bit_not:s@3 @1)) > (bit_not (maxmin @0 @1))) >=20 >=20 > But that does not match here due to the :s. I am not 100% sure but tradin= g 2 > possible bit_not for adding another might end up improving things ... We're lacking a way to say one of the bit_not should be single-used, one multi-use would be OK and a fair trade-off - not sure if that would be enough here, of course. That would mena changing to a condition with single_use ().=