[Bug middle-end/53338] New: [4.8 Regression] Unaligned store generated for aligned data

[Bug middle-end/53338] New: [4.8 Regression] Unaligned store generated for aligned data

[ubizjak at gmail dot com]

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

             Bug #: 53338
           Summary: [4.8 Regression] Unaligned store generated for aligned
                    data
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ubizjak@gmail.com


Following testcase:

--cut here--
#define SIZE 10240

int b[SIZE], c[SIZE];
long long __attribute__((__aligned__ (128))) a[SIZE];

void
imul32_to_64 (void)
{
  int i;

  for (i = 0; i < SIZE; i++)
    a[i] = (long)b[i] * (long)c[i];
}
--cut here--

regressed from 4.7 when compiled with "-O3 -msse4". An unaligned store is
generated in 4.8, where in 4.7 aligned store is used.

4.8:

.L3:
        movdqa  b(%rax), %xmm1
        movdqa  c(%rax), %xmm0
        movdqa  %xmm1, %xmm3
        movdqa  %xmm0, %xmm2
        punpckldq       %xmm1, %xmm3
        punpckldq       %xmm0, %xmm2
        punpckhdq       %xmm1, %xmm1
        punpckhdq       %xmm0, %xmm0
        pmuldq  %xmm3, %xmm2
>>      movdqu  %xmm2, a(%rax,%rax)
        pmuldq  %xmm1, %xmm0
>>      movdqu  %xmm0, a+16(%rax,%rax)
        addq    $16, %rax
        cmpq    $40960, %rax
        jne     .L3

4.7.1:

.L2:
        movdqa  b(%rax), %xmm1
        movdqa  c(%rax), %xmm0
        movdqa  %xmm1, %xmm3
        movdqa  %xmm0, %xmm2
        punpckldq       %xmm1, %xmm3
        punpckldq       %xmm0, %xmm2
        punpckhdq       %xmm1, %xmm1
        punpckhdq       %xmm0, %xmm0
        pmuldq  %xmm3, %xmm2
>>      movdqa  %xmm2, a(%rax,%rax)
        pmuldq  %xmm1, %xmm0
>>      movdqa  %xmm0, a+16(%rax,%rax)
        addq    $16, %rax
        cmpq    $40960, %rax
        jne     .L2

The unaligned store is generated from expr.c, expand_assignment.

[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data

[ubizjak at gmail dot com]

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

--- Comment #1 from Uros Bizjak <ubizjak at gmail dot com> 2012-05-13 19:26:55 UTC ---
(In reply to comment #0)
> Following testcase:
> 
> --cut here--
> #define SIZE 10240
> 
> int b[SIZE], c[SIZE];
> long long __attribute__((__aligned__ (128))) a[SIZE];

This line should read:

long a[SIZE];

[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-05-14
                 CC|                            |jamborm at gcc dot gnu.org
   Target Milestone|---                         |4.8.0
     Ever Confirmed|0                           |1

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> 2012-05-14 03:43:09 UTC ---
It is caused by revision 187101:

http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00097.html

[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-05-14 08:39:03 UTC ---
After IVOPTs we lose the ability to stick the aligned markers at the memory
references.  Before:

  # PT = anything
  # ALIGN = 16, MISALIGN = 0
  vect_pa.21_35 = vect_pa.21_33 + 16;
  MEM[(long int[10240] *)vect_pa.21_35] = vect_var_.20_31;

after:

  MEM[symbol: a, index: ivtmp.29_19, step: 2, offset: 16B] = vect_var_.20_31;

but as ivtmp.29_19 is not of pointer type we do not have 'alignment'
information
for it - thus we do not exploit that it is { 0, +, 16 } in
get_object_alignment_1.
Previously we conservatively assumed "alignment" of TYPE_ALIGN but now we
have "known" alignment due to

      if (TMR_INDEX (exp) && TMR_STEP (exp))
        {
          unsigned HOST_WIDE_INT step = TREE_INT_CST_LOW (TMR_STEP (exp));
          align = MIN (align, (step & -step) * BITS_PER_UNIT);
          known_alignment = true;
        }

(but that results in alignment of 2 bytes based on step) and disregard type
information.

[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data

[ubizjak at gmail dot com]

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

--- Comment #4 from Uros Bizjak <ubizjak at gmail dot com> 2012-05-14 09:03:20 UTC ---
20% runtime regression in rnflow [1] happened in this timeframe, perhaps it
could be attributed to the patch, mentioned in Comment #2.

[1] http://gcc.opensuse.org/c++bench/polyhedron/polyhedron-summary.txt-2-0.html

[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-05-14 09:21:41 UTC ---
> 20% runtime regression in rnflow [1] happened in this timeframe, perhaps it
> could be attributed to the patch, mentioned in Comment #2.

This slowdown is caused by revision 187092 in the proc cptrf2. A further
slowdown (~5%) is caused by revision 187340 in the proc evlrnf. While tracking
these slowdowns I also noticed that for any revision compiling rnflow.f90 is
slower if I use -O3 only compared to the use of -O2 only (cptrf2 seems the
culprit). The best timings I get are when I compile  evlrnf with '-O3
-ffast-math -funroll-loops'.

I am planning to open some PRs about these findings which do not seem related
to this one (unless someone beat me).

[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-05-14 09:32:31 UTC ---
(In reply to comment #5)
> > 20% runtime regression in rnflow [1] happened in this timeframe, perhaps it
> > could be attributed to the patch, mentioned in Comment #2.
> 
> This slowdown is caused by revision 187092 in the proc cptrf2.

That patch was supposed to be a no-op on code generation.

> A further
> slowdown (~5%) is caused by revision 187340 in the proc evlrnf. While tracking
> these slowdowns I also noticed that for any revision compiling rnflow.f90 is
> slower if I use -O3 only compared to the use of -O2 only (cptrf2 seems the
> culprit). The best timings I get are when I compile  evlrnf with '-O3
> -ffast-math -funroll-loops'.
> 
> I am planning to open some PRs about these findings which do not seem related
> to this one (unless someone beat me).

[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-05-14 09:39:20 UTC ---
> That patch was supposed to be a no-op on code generation.

I have opened pr53340.

[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-07 11:49:51 UTC ---
This has been fixed by the most recent re-org of how get_object_alignment
works.