This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/56118] Piecewise vector / complex initialization from constants not combined
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 02 Nov 2015 11:19:23 +0000
- Subject: [Bug tree-optimization/56118] Piecewise vector / complex initialization from constants not combined
- Auto-submitted: auto-generated
- References: <bug-56118-4 at http dot gcc dot gnu dot org/bugzilla/>
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.