[Bug tree-optimization/49442] New: [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[Bug tree-optimization/49442] New: [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

           Summary: [4.5/4.6/4.7 Regression] Misaligned store support
                    pessimization
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org
                CC: irar@gcc.gnu.org, revitale@gcc.gnu.org
            Target: x86_64-linux


__attribute__((noinline, noclone))
void baz (double *out1, double *out2, double *out3, double *in1, double *in2,
int len)
{
  for (int i = 0; i < len; ++i)
    {
      out1[i] = in1[i] * in2[i];
      out2[i] = in1[i] + in2[i];
      out3[i] = in1[i] - in2[i];
    }
}

double a[50000] __attribute__((aligned (32)));
int
main ()
{
  int i;
  for (i = 0; i < 500000; i++)
    baz (a + 0, a + 10000, a + 20000, a + 30000, a + 40000, 10000);
  return 0;
}

is measurably slower in 4.6 compared to 4.4 with -m64 -O3 -mtune=generic,
apparently starting with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148211
at least on Intel CPUs.
with r148210:
Strip out best and worst realtime result
minimum: 6.603036509 sec real / 0.000086529 sec CPU
maximum: 6.720307841 sec real / 0.000159148 sec CPU
average: 6.629486345 sec real / 0.000133896 sec CPU
stdev  : 0.024886889 sec real / 0.000020014 sec CPU
with r148211:
Strip out best and worst realtime result
minimum: 6.969550715 sec real / 0.000072647 sec CPU
maximum: 7.564913575 sec real / 0.000162211 sec CPU
average: 7.192333688 sec real / 0.000135634 sec CPU
stdev  : 0.101616835 sec real / 0.000022659 sec CPU

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.06.16 15:23:05
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-06-16 15:23:05 UTC ---
Does -mtune=barcelona improve it?  What Intel CPUs?  I suppose the vectorizer
cost model could be adjusted for -mtune=generic?  I suppose the old rev.
is equivalent to -fno-tree-vectorize?

On AMD K8 I get

38.26user 0.12system 0:38.42elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k

with vectorization and

31.09user 0.08system 0:31.21elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k

without.  With -mtune=barcelona I get

37.08user 0.20system 0:37.39elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k

and the following with native tuning

32.93user 0.25system 0:33.20elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k

(movlpd instead of movsd and incl instead of add difference to generic only).
So, confirmed on AMD K8 as well.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl at gcc dot gnu.org,
                   |                            |hubicka at gcc dot gnu.org
   Target Milestone|---                         |4.5.4

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-06-16 16:33:16 UTC ---
I was testing on SandyBridge, but it was reported to us for Core2.
The loop used to be vectorized in 4.4 and is now too, in both cases it does a
huge hard to decipher test with many conditions and either uses non-vectorized
loop or vectorized loop.  In the r148210 condition was also:
  vect_p.44_29 = (vector double *) out1_6(D);
  addr2int0.45_28 = (long int) vect_p.44_29;
  vect_p.48_37 = (vector double *) out2_21(D);
  addr2int1.49_38 = (long int) vect_p.48_37;
  orptrs1.50_40 = addr2int0.45_28 | addr2int1.49_38;
  vect_p.53_41 = (vector double *) out3_34(D);
  addr2int2.54_42 = (long int) vect_p.53_41;
  orptrs2.55_51 = orptrs1.50_40 | addr2int2.54_42;
  andmask.56_52 = orptrs2.55_51 & 15;
...
  D.2833_72 = andmask.56_52 == 0;
but in the new condition is not, and previously it used movaps stores in the
loop:
    movapd    %xmm0, (%rdi,%r10)
...
    movapd    %xmm0, (%rsi,%r10)
...
    movapd    %xmm0, (%rdx,%r10)
while newly it uses:
    movlpd    %xmm0, (%rdi,%rbx)
    movhpd    %xmm0, 8(%rdi,%rbx)
...
    movlpd    %xmm0, (%rsi,%rbx)
    movhpd    %xmm0, 8(%rsi,%rbx)
...
    movlpd    %xmm0, (%rdx,%rbx)
    movhpd    %xmm0, 8(%rdx,%rbx)

Surprisingly, the new code is slower even when the pointers aren't aligned:
r128110:
Strip out best and worst realtime result
minimum: 8.849950347 sec real / 0.000085810 sec CPU
maximum: 9.278652529 sec real / 0.000153471 sec CPU
average: 9.055898562 sec real / 0.000138755 sec CPU
stdev  : 0.073603342 sec real / 0.000016469 sec CPU
r128111:
Strip out best and worst realtime result
minimum: 12.089365836 sec real / 0.000081233 sec CPU
maximum: 12.378188295 sec real / 0.000158253 sec CPU
average: 12.234883839 sec real / 0.000136920 sec CPU
stdev  : 0.073461527 sec real / 0.000017463 sec CPU
(same baz routine, and
double a[60000] __attribute__((aligned (32)));
int
main ()
{
  int i;
  for (i = 0; i < 500000; i++)
    baz (a + 1, a + 10001, a + 30000, a + 40000, a + 50000, 10000);
  return 0;
}
instead).  Here, in r128110 generated code it uses the scalar loop, while in
r128111 it uses the vectorized one with those movlpd+movhpd stores.
So in this particular case for this particular CPU, it would be better if the
cost model said that it should verify whether all store pointers are
sufficiently aligned and only use the vectorized loop in that case.

BTW, the vectorization condition is really long, is it a good idea to let it go
through with just a single branch at the end?  Wouldn't it be better to test
several most likely to fail checks first, conditional branch, then some other
tests, again conditional branch?

I've talked with Richard on IRC about how users could promise the compiler
that the pointers are sufficiently aligned and thus it can just assume it is
aligned (if it would test for it) and use it in the loop, both for loads and
stores.  Possibilities include __attribute__((ptr_align (align [, misalign])))
on const pointer parameters and const pointer variables, or adding
__builtin_unreachable () using assertions.

But now that I think about it more, we already version the loop for
vectorization in this case, wouldn't it be better to just add some extension
which would allow the user to say something is likely?  Such hint could be
e.g. hint that some pointer is likely to be so and so aligned/misaligned,
or e.g. that pointers don't overlap (yeah, I know, we have restrict, but
e.g. on STL containers it is more fun to add those)?

E.g. if this loop was hinted that all 5 pointers are 16 byte aligned and
that neither in1[0..len-1] nor in2[0..len-1] overlap out{1,2,3}[0..len-1], the
vectorizer could verify those conditions at runtime and use an correct
alignment
and __restrict assuming faster vectorized loop, while for the fallback case
(vectorization not beneficial, or some overlaps somewhere, or misaligned
pointers) would be a scalar loop not assuming anything of that.
Or perhaps the hints could tell the vectorizer to emit 3 different versions
instead of two, each with different assumptions or something similar.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-06-17 08:15:38 UTC ---
ICC apparently has __assume_aligned (ptr, align) for this, and also
#pragma vector {aligned,unaligned,always,nontemporal}.
For alignment, I'd say having both hard alignment and likely alignment hints
somewhere in the code would be better than ptr_align attribute on the
arguments,
so something like
__builtin_assume_aligned (ptr, align[, misalign])
and
__builtin_likely_aligned (ptr, align[, misalign]);
would be helpful.  The question is if they shouldn't return the pointer again,
and let the user write it in the form
ptr = __builtin_assume_aligned (ptr, 16);
which would be optimized away when we compute the alignment.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[irar at il dot ibm.com]

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

Ira Rosen <irar at il dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |irar at il dot ibm.com

--- Comment #4 from Ira Rosen <irar at il dot ibm.com> 2011-06-19 08:25:05 UTC ---
We can try to fix this with the cost model and additional heuristic in
vect_enhance_data_refs_alignment. Currently we decide not to do versioning for
alignment, because all the accesses are supported anyway. Maybe something like
the following condition for versioning could help (when all the alignment
values are unknown):
if (number_of_loads * cost_of_misaligned_load 
    + number_of_stores * cost_of_misaligned_store
    + approx_vector_iteration_cost_without_drs >
    approx_scalar_iteration_cost * vectorization_factor)
  do_versioning = true;

Ira

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-06-21 12:43:04 UTC ---
Created attachment 24571
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24571
gcc47-builtins.patch

Prerequisite patch for __builtin_assume_aligned patch.  These are just random
things I've noticed when working on that patch.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-06-21 12:50:11 UTC ---
Created attachment 24572
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24572
gcc47-assume-aligned.patch

Current version of the __builtin_assume_aligned support.  On top of the
previous 
patch.
Still unfinished areas:
1) vectorizer/data-refs unfortunately ignores the computed alignment,
   should use get_pointer_alignment/get_object_alignment.
2) it would be nice if the builtin was special cased in the C/C++ FEs and
   acted like
   template <typename T> T __builtin_assume_aligned (T, size_t, ...);
   (for pointer types only) instead of
   void *__builtin_assume_aligned (const void *, size_t, ...);
3) testcases need to be added.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-06-21 12:50:47 UTC ---
Of course something like #c4 is highly desirable independently on this.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-06-30 13:56:46 UTC ---
__builtin_assume_aligned is now supported on the trunk.  Leaving this open even
there so that the default cost model is adjusted.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
           Priority|P3                          |P2

[Bug tree-optimization/49442] [4.5/4.6/4.7/4.8 Regression] Misaligned store support pessimization

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.4                       |4.6.4

--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-02 11:15:02 UTC ---
The 4.5 branch is being closed, adjusting target milestone.

[Bug tree-optimization/49442] [4.7/4.8/4.9 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.4                       |4.7.4

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-12 15:16:46 UTC ---
GCC 4.6.4 has been released and the branch has been closed.

[Bug tree-optimization/49442] [4.7/4.8/4.9/4.10 Regression] Misaligned store support pessimization

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.4                       |4.8.4

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
The 4.7 branch is being closed, moving target milestone to 4.8.4.

[Bug tree-optimization/49442] [4.8/4.9/5 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

[Bug tree-optimization/49442] [4.8/4.9/5/6 Regression] Misaligned store support pessimization

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.5                       |4.9.3

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.

[Bug tree-optimization/49442] [4.9/5/6 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug tree-optimization/49442] [4.9/5/6 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug tree-optimization/49442] [9/10/11/12 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug tree-optimization/49442] [9/10/11/12 Regression] Misaligned store support pessimization

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug tree-optimization/49442] [10/11/12/13 Regression] Misaligned store support pessimization

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug tree-optimization/49442] [10/11/12/13 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug tree-optimization/49442] [11/12/13/14 Regression] Misaligned store support pessimization

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.