[Bug tree-optimization/56118] New: No constant propagation in vector field assignment

[Bug tree-optimization/56118] New: No constant propagation in vector field assignment

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56118

             Bug #: 56118
           Summary: No constant propagation in vector field assignment
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: glisse@gcc.gnu.org
            Target: x86_64-linux-gnu


Hello,

with this code:

#include <x86intrin.h>
__m128d f(){
  __m128d r={3,4};
  r[0]=1;
  r[1]=2;
  return r;
}

gcc sees the following and fails to optimize it:

  r = { 3.0e+0, 4.0e+0 };
  BIT_FIELD_REF <r, 64, 0> = 1.0e+0;
  BIT_FIELD_REF <r, 64, 64> = 2.0e+0;

Nothing fixes it at the RTL level either, so we end up with:

    movapd    .LC0(%rip), %xmm0
    movlpd    .LC1(%rip), %xmm0
    movhpd    .LC2(%rip), %xmm0

[Bug tree-optimization/56118] No constant propagation in vector field assignment

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56118

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> 2013-01-26 17:57:13 UTC ---
Note that the case I am most interested in is actually when r is not
initialized:

  __m128d r;
  gimple_assign <real_cst, BIT_FIELD_REF <r, 64, 0>, 1.0e+0, NULL, NULL>
  gimple_assign <real_cst, BIT_FIELD_REF <r, 64, 64>, 2.0e+0, NULL, NULL>

because I've seen users fill in constant vectors this way. That could
complicate things a little as I'm not sure what r should be between the 2
assignments.

On the side, if SLP is extended to vectors, it might hide this issue (but for
now I've only managed to get an ICE because something takes the address of a
bit_field_ref).

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

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56118

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-01-28
            Summary|No constant propagation in  |Piecewise vector / complex
                   |vector field assignment     |initialization from
                   |                            |constants not combined
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-28 10:44:34 UTC ---
The original testcase is a dup of PR33562, it's a missed dead store
elimination,
not "constant propagation".  The other issue is that we are not combining
adjacent stores (also for other types), we have a PR for that elsewhere, too.
Yes, basic-block vectorization could handle this, but it's probably not the
very best knife to do that job ;)

Related testcases have this issue with _Complex and __real / __imag
piecewise initializations.

Thus, let's make this bug the failure to combine piecewise constant inits
of vectors and complex.

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

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56118

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> 2013-01-28 12:40:21 UTC ---
(In reply to comment #2)
> The original testcase is a dup of PR33562, it's a missed dead store
> elimination, not "constant propagation".

Ah, thanks, I am not very familiar with compiler terminology...

> Related testcases have this issue with _Complex and __real / __imag
> piecewise initializations.

I tried it with _Complex before submitting the PR, and there assigning to the
real part in C code actually shows up in gimple as constructing a complex from
that new value and the imaginary part of the old value, which is then easier to
handle (that reminds me of the vec_concat vs vec_merge discussion about the x86
backend with Uros and rth). But variants might exhibit this issue indeed.

> Thus, let's make this bug the failure to combine piecewise constant inits
> of vectors and complex.

ok.