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 D3DA0385781F; Fri, 17 Feb 2023 14:41:07 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D3DA0385781F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1676644867;
	bh=5uggIL0MrpVfy0a3ZhWk3YCURPvoh1uqmxcbPw0rMJI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ZfGV5l0m1s4raASX2fKHD9sJwOppJpZVMIl5E+H48TNDVQECydmPERxLT1cqpV3UW
	 TTa2oNk8B2YBQFjqlGsTTufIRW2FsaIk7MwSSoHEmjcZDoJrenmvObRV2cMIVzjiXN
	 iREFaEtDZbe8IBmZiHMRo4imYpoqK2pWSQyK/+b8=
From: "gabravier at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/90838] Detect table-based ctz implementation
Date: Fri, 17 Feb 2023 14:41:07 +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: 9.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gabravier at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: wilco at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 10.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-90838-4-N5DnTRLIFw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-90838-4@http.gcc.gnu.org/bugzilla/>
References: <bug-90838-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=3D90838

--- Comment #19 from Gabriel Ravier <gabravier at gmail dot com> ---
(In reply to Jakub Jelinek from comment #14)
> The patch does:
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0bool=C2=A0zero_ok=C2=A0=3D=C2=A0CTZ_=
DEFINED_VALUE_AT_ZERO=C2=A0(TYPE_MODE=C2=A0(type),=C2=A0ctzval)
> =3D=3D=C2=A02;
> +
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0/*=C2=A0Skip=C2=A0if=C2=A0there=C2=
=A0is=C2=A0no=C2=A0value=C2=A0defined=C2=A0at=C2=A0zero,=C2=A0or=C2=A0if=C2=
=A0we=C2=A0can't=C2=A0easily
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return=C2=A0the=C2=A0cor=
rect=C2=A0value=C2=A0for=C2=A0zero.=C2=A0=C2=A0*/
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if=C2=A0(!zero_ok)
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return=C2=A0false;
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if=C2=A0(zero_val=C2=A0!=3D=C2=A0ctz=
val=C2=A0&&=C2=A0!(zero_val=C2=A0=3D=3D=C2=A00=C2=A0&&=C2=A0ctzval=C2=A0=3D=
=3D=C2=A0type_size))
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return=C2=A0false;
> For CTZ_DEFINED_VALUE_AT_ZERO =3D=3D 1 we could support it the same way b=
ut we'd
> need
> to emit into the IL an equivalent of val =3D=3D 0 ? zero_val : .CTZ (val)=
 (with
> GIMPLE_COND and a separate bb - not sure if anything in forwprop creates =
new
> basic blocks right now), where there is a high chance that RTL opts would
> turn it back into unconditional
> ctz.
> That still wouldn't help non--mbmi x86, because CTZ_DEFINED_VALUE_AT_ZERO=
 is
> 0 there.
> We could handle even that case by doing the branches around, but those wo=
uld
> stay there
> in the generated code, at which point I wonder whether it would be a win.=
=20
> The original
> code is branchless...

If the original code being branchless makes it faster, wouldn't that imply =
that
we should use the table-based implementation when generating code for
`__builtin_ctz` ?=