public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/32273] New: 'restrict' is forgotten after loop unrolling
@ 2007-06-10 14:47 tomash dot brechko at gmail dot com
2007-06-10 20:07 ` [Bug middle-end/32273] " rguenth at gcc dot gnu dot org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: tomash dot brechko at gmail dot com @ 2007-06-10 14:47 UTC (permalink / raw)
To: gcc-bugs
The following two functions are equivalent (especially after loop unrolling):
void
foo(const int *restrict a, int *restrict b, int *restrict c)
{
b[0] += a[0];
c[0] += a[0];
b[1] += a[1];
c[1] += a[1];
}
void
bar(const int *restrict a, int *restrict b, int *restrict c)
{
for (int i = 0; i < 2; ++i)
{
b[i] += a[i];
c[i] += a[i];
}
}
However gcc forgets about 'restrict' after the first iteration of the loop, and
foo() and bar() produce different code:
foo:
pushl %ebx
movl 8(%esp), %ebx
movl 12(%esp), %eax
movl 16(%esp), %edx
movl (%ebx), %ecx
addl %ecx, (%eax)
addl %ecx, (%edx) ;; Correct: no reloading of (%ebx) is needed.
movl 4(%ebx), %ecx
addl %ecx, 4(%eax)
addl %ecx, 4(%edx) ;; Correct: no reloading of 4(%ebx) is needed.
popl %ebx
ret
bar:
pushl %ebx
movl 8(%esp), %ebx
movl 12(%esp), %edx
movl 16(%esp), %ecx
movl (%ebx), %eax
addl %eax, (%edx)
addl %eax, (%ecx) ;; Correct: no reloading of (%ebx) is needed.
movl 4(%ebx), %eax
addl %eax, 4(%edx)
movl 4(%ebx), %eax ;; BUG: unnecessary reloading of 4(%ebx).
addl %eax, 4(%ecx)
popl %ebx
ret
For any number of iterations only the first iteration honors the 'restrict'
qualifier. This is wrong, because 'restrict' is a property of a pointer, not
data, so if p and q pointers reference different objects, then (p + OFF1) and
(q + OFF2) also expected to reference different objects. Correct assembler for
foo() supports that.
--
Summary: 'restrict' is forgotten after loop unrolling
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tomash dot brechko at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32273
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug middle-end/32273] 'restrict' is forgotten after loop unrolling
2007-06-10 14:47 [Bug c/32273] New: 'restrict' is forgotten after loop unrolling tomash dot brechko at gmail dot com
@ 2007-06-10 20:07 ` rguenth at gcc dot gnu dot org
2007-06-10 22:41 ` dberlin at gcc dot gnu dot org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2007-06-10 20:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-10 20:07 -------
Danny, as looked at restrict handling a few days ago - maybe you know instantly
why it doesn't work ;) (apart from us not recomputing aliasing after loop
optimizations on the tree level -- and the complete unrolling happens there)
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dberlin at gcc dot gnu dot
| |org, rguenth at gcc dot gnu
| |dot org
Keywords| |alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32273
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug middle-end/32273] 'restrict' is forgotten after loop unrolling
2007-06-10 14:47 [Bug c/32273] New: 'restrict' is forgotten after loop unrolling tomash dot brechko at gmail dot com
2007-06-10 20:07 ` [Bug middle-end/32273] " rguenth at gcc dot gnu dot org
@ 2007-06-10 22:41 ` dberlin at gcc dot gnu dot org
2007-06-10 22:55 ` pinskia at gcc dot gnu dot org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: dberlin at gcc dot gnu dot org @ 2007-06-10 22:41 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from dberlin at gcc dot gnu dot org 2007-06-10 22:41 -------
Complete guess:
alias.c relies not on TYPE_RESTRICT, but on DECL_BASED_ON_RESTRICT_P
I never noticed we even had such a thing :)
My guess is that loop unrolling makes new ssa names, and when they get
transformed during un-ssa, this flag no longer exists on them.
Realistically, may-alias should propagate the DECL_* stuff to
SSA_NAME_PTR_INFO, which loop unrolling copies.
When they get un-ssa'd, we should then copy the restrict info from the ssa name
back to the base variable we create.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32273
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug middle-end/32273] 'restrict' is forgotten after loop unrolling
2007-06-10 14:47 [Bug c/32273] New: 'restrict' is forgotten after loop unrolling tomash dot brechko at gmail dot com
2007-06-10 20:07 ` [Bug middle-end/32273] " rguenth at gcc dot gnu dot org
2007-06-10 22:41 ` dberlin at gcc dot gnu dot org
@ 2007-06-10 22:55 ` pinskia at gcc dot gnu dot org
2007-06-11 0:22 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-06-10 22:55 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-10 22:55 -------
This works on the pointer_plus branch :) Also Predictive commoning fixes it up
even without unrolling at the tree level so it works at -O3 (this is on the
pointer_plus branch I have not tried on the mainline).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32273
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug middle-end/32273] 'restrict' is forgotten after loop unrolling
2007-06-10 14:47 [Bug c/32273] New: 'restrict' is forgotten after loop unrolling tomash dot brechko at gmail dot com
` (2 preceding siblings ...)
2007-06-10 22:55 ` pinskia at gcc dot gnu dot org
@ 2007-06-11 0:22 ` pinskia at gcc dot gnu dot org
2007-06-16 5:49 ` [Bug tree-optimization/32273] " pinskia at gcc dot gnu dot org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-06-11 0:22 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-11 00:21 -------
Yes this is fixed on the pointer_plus branch, the pointer_plus branch is better
at keeping track of what the decl is the restrict pointer's base.
-;; *D.1537 = *D.1539 + *D.1537
+;; *D.1538 = *D.1541 + *D.1538
(insn 14 13 15 t.c:16 (set (reg:SI 66)
- (mem:SI (reg:SI 59 [ D.1539 ]) [8 S4 A32])) -1 (nil)
+ (mem:SI (reg:SI 59 [ D.1541 ]) [2 S4 A32])) -1 (nil)
(nil))
(insn 15 14 0 t.c:16 (parallel [
- (set (mem:SI (reg:SI 60 [ D.1537 ]) [7 S4 A32])
- (plus:SI (mem:SI (reg:SI 60 [ D.1537 ]) [7 S4 A32])
+ (set (mem:SI (reg:SI 60 [ D.1538 ]) [2 S4 A32])
+ (plus:SI (mem:SI (reg:SI 60 [ D.1538 ]) [2 S4 A32])
(reg:SI 66)))
(clobber (reg:CC 17 flags))
]) -1 (nil)
- (expr_list:REG_EQUAL (plus:SI (mem:SI (reg:SI 60 [ D.1537 ]) [7 S4 A32])
- (mem:SI (reg:SI 59 [ D.1539 ]) [8 S4 A32]))
+ (expr_list:REG_EQUAL (plus:SI (mem:SI (reg:SI 60 [ D.1538 ]) [2 S4 A32])
+ (mem:SI (reg:SI 59 [ D.1541 ]) [2 S4 A32]))
(nil)))
See how the - has different aliasing sets than the +, the - has the correct
aliasing set.
So this is now mine.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
GCC target triplet|i686-pc-linux-gnu |
Last reconfirmed|0000-00-00 00:00:00 |2007-06-11 00:21:57
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32273
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/32273] 'restrict' is forgotten after loop unrolling
2007-06-10 14:47 [Bug c/32273] New: 'restrict' is forgotten after loop unrolling tomash dot brechko at gmail dot com
` (3 preceding siblings ...)
2007-06-11 0:22 ` pinskia at gcc dot gnu dot org
@ 2007-06-16 5:49 ` pinskia at gcc dot gnu dot org
2007-06-24 3:38 ` pinskia at gcc dot gnu dot org
2008-10-01 14:37 ` rguenth at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-06-16 5:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-16 05:49 -------
Fixed at revision 125755 on the trunk by the merge of the pointer_plus. Though
this is now a TREE level missed optimization so unassigning me.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED |NEW
Component|middle-end |tree-optimization
Keywords| |TREE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32273
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/32273] 'restrict' is forgotten after loop unrolling
2007-06-10 14:47 [Bug c/32273] New: 'restrict' is forgotten after loop unrolling tomash dot brechko at gmail dot com
` (4 preceding siblings ...)
2007-06-16 5:49 ` [Bug tree-optimization/32273] " pinskia at gcc dot gnu dot org
@ 2007-06-24 3:38 ` pinskia at gcc dot gnu dot org
2008-10-01 14:37 ` rguenth at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-06-24 3:38 UTC (permalink / raw)
To: gcc-bugs
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32273
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/32273] 'restrict' is forgotten after loop unrolling
2007-06-10 14:47 [Bug c/32273] New: 'restrict' is forgotten after loop unrolling tomash dot brechko at gmail dot com
` (5 preceding siblings ...)
2007-06-24 3:38 ` pinskia at gcc dot gnu dot org
@ 2008-10-01 14:37 ` rguenth at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-10-01 14:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 14:35 -------
PR14187 again.
*** This bug has been marked as a duplicate of 14187 ***
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32273
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-10-01 14:37 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-06-10 14:47 [Bug c/32273] New: 'restrict' is forgotten after loop unrolling tomash dot brechko at gmail dot com
2007-06-10 20:07 ` [Bug middle-end/32273] " rguenth at gcc dot gnu dot org
2007-06-10 22:41 ` dberlin at gcc dot gnu dot org
2007-06-10 22:55 ` pinskia at gcc dot gnu dot org
2007-06-11 0:22 ` pinskia at gcc dot gnu dot org
2007-06-16 5:49 ` [Bug tree-optimization/32273] " pinskia at gcc dot gnu dot org
2007-06-24 3:38 ` pinskia at gcc dot gnu dot org
2008-10-01 14:37 ` rguenth at gcc dot gnu dot 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).