public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/53338] New: [4.8 Regression] Unaligned store generated for aligned data
@ 2012-05-13 19:27 ubizjak at gmail dot com
2012-05-13 22:07 ` [Bug middle-end/53338] " ubizjak at gmail dot com
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: ubizjak at gmail dot com @ 2012-05-13 19:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
2012-05-13 19:27 [Bug middle-end/53338] New: [4.8 Regression] Unaligned store generated for aligned data ubizjak at gmail dot com
@ 2012-05-13 22:07 ` ubizjak at gmail dot com
2012-05-14 4:41 ` hjl.tools at gmail dot com
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: ubizjak at gmail dot com @ 2012-05-13 22:07 UTC (permalink / raw)
To: gcc-bugs
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];
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
2012-05-13 19:27 [Bug middle-end/53338] New: [4.8 Regression] Unaligned store generated for aligned data ubizjak at gmail dot com
2012-05-13 22:07 ` [Bug middle-end/53338] " ubizjak at gmail dot com
@ 2012-05-14 4:41 ` hjl.tools at gmail dot com
2012-05-14 8:51 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: hjl.tools at gmail dot com @ 2012-05-14 4:41 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
2012-05-13 19:27 [Bug middle-end/53338] New: [4.8 Regression] Unaligned store generated for aligned data ubizjak at gmail dot com
2012-05-13 22:07 ` [Bug middle-end/53338] " ubizjak at gmail dot com
2012-05-14 4:41 ` hjl.tools at gmail dot com
@ 2012-05-14 8:51 ` rguenth at gcc dot gnu.org
2012-05-14 9:22 ` ubizjak at gmail dot com
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-05-14 8:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
2012-05-13 19:27 [Bug middle-end/53338] New: [4.8 Regression] Unaligned store generated for aligned data ubizjak at gmail dot com
` (2 preceding siblings ...)
2012-05-14 8:51 ` rguenth at gcc dot gnu.org
@ 2012-05-14 9:22 ` ubizjak at gmail dot com
2012-05-14 9:24 ` dominiq at lps dot ens.fr
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: ubizjak at gmail dot com @ 2012-05-14 9:22 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
2012-05-13 19:27 [Bug middle-end/53338] New: [4.8 Regression] Unaligned store generated for aligned data ubizjak at gmail dot com
` (3 preceding siblings ...)
2012-05-14 9:22 ` ubizjak at gmail dot com
@ 2012-05-14 9:24 ` dominiq at lps dot ens.fr
2012-05-14 9:34 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-05-14 9:24 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
2012-05-13 19:27 [Bug middle-end/53338] New: [4.8 Regression] Unaligned store generated for aligned data ubizjak at gmail dot com
` (4 preceding siblings ...)
2012-05-14 9:24 ` dominiq at lps dot ens.fr
@ 2012-05-14 9:34 ` rguenth at gcc dot gnu.org
2012-05-14 9:44 ` dominiq at lps dot ens.fr
2012-09-07 11:50 ` rguenth at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-05-14 9:34 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
2012-05-13 19:27 [Bug middle-end/53338] New: [4.8 Regression] Unaligned store generated for aligned data ubizjak at gmail dot com
` (5 preceding siblings ...)
2012-05-14 9:34 ` rguenth at gcc dot gnu.org
@ 2012-05-14 9:44 ` dominiq at lps dot ens.fr
2012-09-07 11:50 ` rguenth at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-05-14 9:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
2012-05-13 19:27 [Bug middle-end/53338] New: [4.8 Regression] Unaligned store generated for aligned data ubizjak at gmail dot com
` (6 preceding siblings ...)
2012-05-14 9:44 ` dominiq at lps dot ens.fr
@ 2012-09-07 11:50 ` rguenth at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-09-07 11:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-09-07 11:50 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-13 19:27 [Bug middle-end/53338] New: [4.8 Regression] Unaligned store generated for aligned data ubizjak at gmail dot com
2012-05-13 22:07 ` [Bug middle-end/53338] " ubizjak at gmail dot com
2012-05-14 4:41 ` hjl.tools at gmail dot com
2012-05-14 8:51 ` rguenth at gcc dot gnu.org
2012-05-14 9:22 ` ubizjak at gmail dot com
2012-05-14 9:24 ` dominiq at lps dot ens.fr
2012-05-14 9:34 ` rguenth at gcc dot gnu.org
2012-05-14 9:44 ` dominiq at lps dot ens.fr
2012-09-07 11:50 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).