[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53338 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Richard Guenther 2012-09-07 11:49:51 UTC --- This has been fixed by the most recent re-org of how get_object_alignment works.
[Bug middle-end/53338] [4.8 Regression] Unaligned store generated for aligned data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53338 --- Comment #7 from Dominique d'Humieres 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53338 --- Comment #6 from Richard Guenther 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53338 --- Comment #5 from Dominique d'Humieres 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53338 --- Comment #4 from Uros Bizjak 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53338
Richard Guenther changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #3 from Richard Guenther 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53338 H.J. Lu 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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53338 --- Comment #1 from Uros Bizjak 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];
