On Thu, 1 Oct 2026, Jakub Jelinek wrote:
> On Thu, Oct 01, 2026 at 09:43:12AM +0200, Richard Biener wrote:
> > works, I wonder why we had the mode check there ... I'm testing this.
>
> When Richard Sandiford introduced it back in 2015, at least for clz/ctz
> it was using TYPE_MODE in the C?Z_DEFINED_VALUE_AT_ZERO cases and for the
> rest it would be supported for scalar integer modes only anyway.
> Now it uses SCALAR_INT_TYPE_MODE in those cases, so will also ICE if it is
> not like that, but BITINT_TYPE is an exception:
> if (wi::ne_p (arg, 0))
> tmp = wi::clz (arg);
> else if (BITINT_TYPE_P (arg_type))
> tmp = TYPE_PRECISION (arg_type);
> else if (!CLZ_DEFINED_VALUE_AT_ZERO (SCALAR_INT_TYPE_MODE (arg_type),
> tmp))
> tmp = TYPE_PRECISION (arg_type);
> Except the
> if (SCALAR_INT_MODE_P (mode))
> check is not about the argument type (types) but about the result type.
> When it was introduced, all the handled functions
> (ffs/clz/ctz/clrsb/popcount/parity) had int return type, check for argument
> mode would be
> if (SCALAR_INT_MODE_P (arg_mode))
> in one case and
> if (SCALAR_INT_MODE_P (arg0_mode))
> in the other case.
> I'd say we can just remove the if conditions altogether,
> fold_const_call_ss{,s} will just return false for unknown builtins and
> for the known ones that it handles all the results are BITINT_TYPE or
> SCALAR_INT_MODE_P ones.
I think it makes sense to gate on the return type just for the sake
of early out - I suppose it was supposed to gate the opposite of
real_cst_p (arg) && INTEGRAL_TYPE_P (type) (which also uses a type
check). It also acts as somewhat of a safety against those
pesky invalid testcases prototyping existing builtins with bogus types...
Richard.
