https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56118
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
From the dup:
Confirmed. Note that with the existing way of doing this (BIT_FIELD_REF on the
LHS) it's especially hard to get this combined.
Introducing BIT_FIELD_EXPR would help here (google for old patches). We'd have
vec_1 = { 0.0, 0.0 };
vec_2 = BIT_FIELD_EXPR <vec_1, 3.1400001049041748046875e+0, 32, 0>;
vec_3 = BIT_FIELD_EXPR <vec_2, 2.71000003814697265625e+0, 32, 32>;
which we can easily constant fold. Of course this would continue the
(ab-)use of BIT_FIELD_* for vectors. Enhancing VEC_PERM to allow the
2nd input (vector) to be of different size (or scalar) would make
vec_2 = VEC_PERM <vec_1, 3.1400001049041748046875e+0, { 0, 3 }>
possible (which is also only ternary instead of quaternary). Expansion
can go the vec_insert route or fallback to splat + perm_const.
VEC_PERM would become more of the RTL pattern
(vec_select
(vec_concat ...) ...)
Modeling element extraction with VEC_PERM would be a bit awkward (you'd
have a stale operand). So if we end up with a vector extract tree code
(not using BIT_FIELD_EXPR anymore for that) then an explicit vector insert
would make sense as well.
The only reason BIT_FIELD_EXPR isn't in trunk yet is that it has four
operands (a "first" if done properly tuplish, we'd not want it as a
"single" RHS). Though the size operand is somewhat redundant if we
require (as for BIT_FIELD_REF) matching bitsize with the operand to insert.
That said, the fix is to fix the representation, not somehow make the
existing one optimized.
