https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128180
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Blocks| |53947
Last reconfirmed| |2026-10-26
CC| |rguenth at gcc dot gnu.org,
| |tnfchris at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Konstantinos Eleftheriou from comment #0)
...
>
> The attached reduced.c is a smaller example. At -O3, its loop body before
> vectorization is:
>
> _5 = MEM <uint128_t> [(char * {ref-all})in_28];
> MEM <uint128_t> [(char * {ref-all})out_27] = _5;
> _2 = BIT_FIELD_REF <_5, 32, 0>;
> _1 = _2 * 2.0e+0;
> *out_27 = _1;
> _10 = BIT_FIELD_REF <_5, 32, 32>;
> _3 = _10 * 2.0e+0;
> MEM[(float *)out_27 + 4B] = _3;
> _22 = BIT_FIELD_REF <_5, 32, 64>;
> _4 = _22 * 2.0e+0;
> MEM[(float *)out_27 + 8B] = _4;
>
> and the vectorizer reports:
>
> missed: not vectorized: no vectype for stmt: _5 = MEM <uint128_t> [(char *
> {ref-all})in_28];
For BB vectorization this would be a case where _5 can be considered a
pre-existing vector (even if the register is not vector typed - the
BIT_FIELD_REFs access the register which is suitable for bitwise storage
consistently with V4SI).
For loop vectorization this would similarly be a pre-existing vector
"compatible" load and re-vectorization should appply.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
