[Bug tree-optimization/61619] New: Benefits from -ftree-vectorize lost easily when changing unrelated code

[Bug tree-optimization/61619] New: Benefits from -ftree-vectorize lost easily when changing unrelated code

[shmueller2 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61619

            Bug ID: 61619
           Summary: Benefits from -ftree-vectorize lost easily when
                    changing unrelated code
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: shmueller2 at gmail dot com

Created attachment 33011
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33011&action=edit
Uncommenting (1), (2) or (3) significantly accelerates this code

When compiling the attached code with:

g++-4.9 -std=c++11 -O3 -Wall -Wextra -pedantic bug.cpp -o bug

I found that minor changes in seemingly irrelevant aspects of the code had a
strong effect on performance. When run with:

time ./bug

the code as attached gave the following best-of-10 timing on a 2011 Macbook
Air:

real   0m1.718s
user   0m1.395s
sys    0m0.306s

Minor changes by uncommenting any of the lines marked with (1), (2), (3)
(replacing the line immediately above) yielded significantly better results:

Uncomment line (1):

real   0m1.343s
user   0m1.029s
sys    0m0.312s

Uncomment line (2):

real   0m1.364s
user   0m1.062s
sys    0m0.297s

Uncomment line (3):

real   0m1.332s
user   0m1.016s
sys    0m0.315s

The generated assembly code (-S) differs significantly in all cases. When using

-fno-tree-vectorize

the performance is similar to the first (slow) result for all variations. 

The bug I'm reporting is that the optimization benefits from -ftree-vectorize
are apparently lost easily and non-transparently when changing seemingly
unrelated parts of the code on a high level, which should not affect
performance. 

I would have expected that none of the changes (1), (2) and (3) would have
resulted in a difference in the generated assembly code, and it was very
surprising to me that such details mattered so much.

[Bug tree-optimization/61619] Benefits from -ftree-vectorize lost easily when changing unrelated code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61619

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-06-26
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
bug.cpp:69:13: note: not vectorized: number of iterations cannot be computed.
bug.cpp:69:13: note: bad loop form.

The loop is

  <bb 20>:
  # sum_62 = PHI <sum_42(19), [bug.cpp : 69:80] sum_33(21)>
  # p_71 = PHI <p_59(19), [bug.cpp : 29:29] p_50(21)>
  [bug.cpp : 69:80] _32 = [bug.cpp : 69] *p_71;
  [bug.cpp : 69:80] sum_33 = sum_62 + _32;
  [bug.cpp : 29:31] p_50 = p_71 + pretmp_7;
  [bug.cpp : 69:13] if (_48 != p_50)
    goto <bb 21>;
  else
    goto <bb 22>;

  <bb 21>:
  goto <bb 20>;

The above is with -fopt-info-vec-missed and the excerpt is from the
bug.cpp.114t.vect file produced by -fdump-tree-vect-details-lineno

I believe the issue is that the initialization of S and E are not
inlined if none of the uncomments are done.  If you expect all
abstraction to be removed by inlining the 'flatten' attribute can do magic.

Unfortunately the inits look like

  [/usr/include/c++/4.9/bits/stl_algobase.h : 378:6] MEM[(char * {ref-all})&S]
= MEM[(char * {ref-all})&._94];
  pretmp_22 = MEM[(struct array *)&S];

which we don't fold to the constant init 1 for some reason.

[Bug tree-optimization/61619] Benefits from -ftree-vectorize lost easily when changing unrelated code

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61619

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Unfortunately the inits look like
> 
>   [/usr/include/c++/4.9/bits/stl_algobase.h : 378:6] MEM[(char *
> {ref-all})&S] = MEM[(char * {ref-all})&._94];
>   pretmp_22 = MEM[(struct array *)&S];
> 
> which we don't fold to the constant init 1 for some reason.

Sounds related to PR 59611 (I didn't look at this one closely, so maybe not).

[Bug tree-optimization/61619] Benefits from -ftree-vectorize lost easily when changing unrelated code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61619

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |jamborm at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
._94/3491 (constexpr const long unsigned int ._94 [1]) @0x7ffff1d5ca90
  Type: variable definition analyzed
  Visibility: prevailing_def_ironly artificial
  References:
  Referring: main/3232 (read)
  Availability: available
  Varpool flags: initialized read-only const-value-known

Ok, for the above SRA fails to do a scalar replacement and value-numbering
doesn't even reach the aggregate copy from the constant initializer.
That's because only PRE exposes it and PRE doesn't do all the fancy VN
tricks.

I suppose I have to look closer at some point.  Interesting testcase
showing possible issues with C++ constexpr initializers.

Note that we also have

  MEM[(char * {ref-all})&S] = MEM[(char * {ref-all})&._94];   

but this aggregate copy has sizeof (long) so we could have optimized it
(it's ref-all already) to use an integer type.

This is lowered from

  array<long unsigned int, 1ul>::array (&S, (const struct initializer_list &)
&TARGET_EXPR <D.64552, {._M_array=(const long unsigned int *) &._94,
._M_len=1}>)

to

        D.64552._M_array = &._94;
        D.64552._M_len = 1;
        try
          {
            array<long unsigned int, 1ul>::array (&S, &D.64552);
          }

which eventually ends up calling memmove which we optimize to the aggregate
assignment.

[Bug tree-optimization/61619] Benefits from -ftree-vectorize lost easily when changing unrelated code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61619

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |61473

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is fixed by the patch for PR61473.

[Bug tree-optimization/61619] Benefits from -ftree-vectorize lost easily when changing unrelated code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61619
Bug 61619 depends on bug 61473, which changed state.

Bug 61473 Summary: register sized memmove not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61473

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

[Bug tree-optimization/61619] Benefits from -ftree-vectorize lost easily when changing unrelated code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61619

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to work|                            |4.10.0
         Resolution|---                         |FIXED

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.