https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122478
--- Comment #9 from Artemiy Volkov <artemiyv at acm dot org> ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Artemiy Volkov from comment #7)
> > FWIW, I have
> >
> > diff --git a/gcc/match.pd b/gcc/match.pd
> > index 00493d6ad99..88216c7ee53 100644
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -5658,10 +5658,10 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >
> > /* Squash view_converts of BFRs if no precision is lost. */
> > (simplify
> > - (view_convert (BIT_FIELD_REF @1 @2 @3))
> > + (view_convert (BIT_FIELD_REF@0 @1 @2 @3))
> > (if (is_gimple_reg_type (type)
> > && (!INTEGRAL_TYPE_P (type)
> > - || type_has_mode_precision_p (type)))
> > + || TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0))))
> > (BIT_FIELD_REF:type @1 @2 @3)))
> >
> > /* For integral conversions with the same precision or pointer
> >
> > spinning on everything at the moment. (As you say, this will provide
> > type_has_mode_precision_p (TREE_TYPE (@0)) implicitly.)
>
> I am thinking if this could fail. For an example extracting a vector from a
> vector could cause TYPE_PRECISION to ICE.
>
> That is:
> ```
> #define vect4 __attribute__((vector_size(4)))
> #define vect8 __attribute__((vector_size(8)))
>
> int f(vect8 int a)
> {
> vect4 int b = __builtin_shufflevector (a, a, 0);
> return (int)b;
> }
> ```
> Which gives us:
> ```
> b_2 = BIT_FIELD_REF <a_1(D), 32, 0>;
> _3 = VIEW_CONVERT_EXPR<int>(b_2);
> ```
Ah yes of course, s/TYPE_PRECISION/TYPE_PRECISION_RAW/g, but since the latter
can't be open-coded comment #5 is the next best thing.
