On 7/7/2026 4:47 AM, Eikansh Gupta wrote:
The `IFN_CLZ/IFN_CTZ` pattern seems too permissive
I will change the check to `>= precision`.
Ugh. Looks like I left the LLM bits in again. I need to adjust my
mailer so that it tells me when I likely make this mistake as it's
happened repeatedly. Ignore the LLM slop.
> This adds match.pd simplifications for min(clz(x), clz(y)) and
> min(ctz(x), ctz(y)) to clz(x | y) and ctz(x | y).
>
> PR tree-optimization/123311
>
> gcc/ChangeLog:
>
> * match.pd (min(clz(x), clz(y)) -> clz(x | y)): New pattern.
> (min(ctz(x), ctz(y)) -> ctz(x | y)): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/tree-ssa/pr123311.c: New test.
Don't we have to test the CLZ_DEFINED_VALUE_AT_ZERO and
CTZ_DEFINED_VALUE_AT_ZERO?
__builtin_ctz(0)/clz already has undefined behaviour and
IFN_CTZ/IFN_CLZ defines the value at zero. Is the above test still needed?
Thanks for pushing back. Looking at it again I think we're OK. So a
nonissue.
> +/* min (clz (x), clz (y)) -> clz (x | y) and
> + min (ctz (x), ctz (y)) -> ctz (x | y). */
> +(for func (CLZ CTZ)
> + (simplify
> + (min (func:s @0) (func:s @1))
> + (if (types_match (@0, @1)
> + && (!sanitize_flags_p (SANITIZE_BUILTIN)
> + || (cfun && (cfun->curr_properties & PROP_ssa) != 0)))
Hmm. Can you explain what these two trailing conditions are doing
as a
comment in this patch?
I'm guessing you want to give the sanitizers a chance to
instrument the
builtin? But better to be sure.
The patch https://gcc.gnu.org/cgit/gcc/commit?id=f7d1b9cd added it to
other ctz/clz patterns. I did the same for the new pattern.
This is added for UBSan to instrument similar to other CTZ/CLZ
patterns in match.pd. IFN_CTZ does not have this check in other patterns.
Understood. Thanks for the clarification. Send a final version which
I expect I'll ACK and you'll be able to commit once your account is set
up and keys installed.
jeff
