This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/56118] Piecewise vector / complex initialization from constants not combined


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]