On Wed, 16 Sep 2026, Jakub Jelinek wrote:
> On Wed, Sep 16, 2026 at 11:29:40AM +0200, Richard Biener wrote:
> > Like this? Tested to fail without the patch and pass with it.
>
> LGTM with a nit (and assuming we try to handle at least some of this
> in tree-vect-patterns.cc eventually).
Fixed and pushed. We can handle some cases with patterns, yes.
Generally the situation will be similar as with long : 33 and
friends - arithmetic would need fixup after each operation or
carefully placed promotion/demotion after a sequence of
operations. if-conversion lowers bitfield loads and stores
and bitwise operations accept non-mode precision operands as
do some conversions. We could simply extend if-conversion
bitfield lowering to also lower _BitInt loads/stores and
thing of generally handling to-bitfield conversions by
performing the required masking in vectorizable_conversion
directly rather than somehow using patterns for that.
I plan to pick this series of defensive patches to branches btw.
which is why I didn't want to do the above first.
Richard.
> > --- a/gcc/tree-vect-stmts.cc
> > +++ b/gcc/tree-vect-stmts.cc
> > @@ -5413,6 +5413,17 @@ vectorizable_conversion (vec_info *vinfo,
> > "type conversion to bit-precision unsupported\n");
> > return false;
> > }
>
> There should be empty line here.
>
> > + /* _BitInt values are not sign-/zero-extended to mode precision. */
> > + if (!VECTOR_BOOLEAN_TYPE_P (vectype_out)
> > + && TREE_CODE (rhs_type) == BITINT_TYPE
> > + && !type_has_mode_precision_p (rhs_type))
> > + {
> > + if (dump_enabled_p ())
> > + dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> > + "type conversion from _BitInt unsupported\n");
> > + return false;
> > + }
> > +
>
> Rather than one superfluous empty line here.
>
> > if (op_type == binary_op)
> > {
> > --
> > 2.51.0
>
> Jakub
>
>
--
Richard Biener <[email protected]>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri; (HRB 36809, AG Nuernberg)
