* [Bug middle-end/14192] Restrict pointers don't help
2004-02-18 13:55 [Bug middle-end/14192] New: Restrict pointers don't help hoogerbrugge at hotmail dot com
@ 2004-02-18 14:11 ` pinskia at gcc dot gnu dot org
2004-02-18 14:15 ` pinskia at gcc dot gnu dot org
` (7 subsequent siblings)
8 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-02-18 14:11 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-02-18 14:10 -------
*** Bug 14193 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/14192] Restrict pointers don't help
2004-02-18 13:55 [Bug middle-end/14192] New: Restrict pointers don't help hoogerbrugge at hotmail dot com
2004-02-18 14:11 ` [Bug middle-end/14192] " pinskia at gcc dot gnu dot org
@ 2004-02-18 14:15 ` pinskia at gcc dot gnu dot org
2004-02-18 15:33 ` hoogerbrugge at hotmail dot com
` (6 subsequent siblings)
8 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-02-18 14:15 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-02-18 14:15 -------
I cannot reproduce the problem you are having on powerpc-apple-darwin or i686-pc-linux-gnu with
3.5-tree-ssa 20040208 (merged 20040126) or 3.5.0 20040204.
--
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pessimizes-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/14192] Restrict pointers don't help
2004-02-18 13:55 [Bug middle-end/14192] New: Restrict pointers don't help hoogerbrugge at hotmail dot com
2004-02-18 14:11 ` [Bug middle-end/14192] " pinskia at gcc dot gnu dot org
2004-02-18 14:15 ` pinskia at gcc dot gnu dot org
@ 2004-02-18 15:33 ` hoogerbrugge at hotmail dot com
2004-02-19 14:02 ` hoogerbrugge at hotmail dot com
` (5 subsequent siblings)
8 siblings, 0 replies; 15+ messages in thread
From: hoogerbrugge at hotmail dot com @ 2004-02-18 15:33 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From hoogerbrugge at hotmail dot com 2004-02-18 15:33 -------
I just did a update to version 3.5.0 20040218 and the problem is still there.
Are you not able to reproduce it because you don't have the sources of the my
target port? If so, should I sent sources of the port?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/14192] Restrict pointers don't help
2004-02-18 13:55 [Bug middle-end/14192] New: Restrict pointers don't help hoogerbrugge at hotmail dot com
` (2 preceding siblings ...)
2004-02-18 15:33 ` hoogerbrugge at hotmail dot com
@ 2004-02-19 14:02 ` hoogerbrugge at hotmail dot com
2004-10-11 10:56 ` giovannibajo at libero dot it
` (4 subsequent siblings)
8 siblings, 0 replies; 15+ messages in thread
From: hoogerbrugge at hotmail dot com @ 2004-02-19 14:02 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From hoogerbrugge at hotmail dot com 2004-02-19 14:02 -------
I can demonstrate the problem on ia64. Here are three cases:
int zero_restrict_pointers(int *p, int *q)
{
*p = 0;
return *q;
}
int one_restrict_pointer(int *restrict p, int *q)
{
*p = 0;
return *q;
}
int two_restrict_pointers(int *restrict p, int *restrict q)
{
*p = 0;
return *q;
}
This gives the following ia64 code (version 20040217):
.pred.safe_across_calls p1-p5,p16-p63
.text
.align 16
.global zero_restrict_pointers#
.proc zero_restrict_pointers#
zero_restrict_pointers:
.prologue
.body
.mmb
nop 0
st4 [r32] = r0
nop 0
.mbb
ld4 r8 = [r33]
nop 0
br.ret.sptk.many b0
.endp zero_restrict_pointers#
.align 16
.global one_restrict_pointer#
.proc one_restrict_pointer#
one_restrict_pointer:
.prologue
.body
.mmb
nop 0
st4 [r32] = r0
nop 0
.mbb
ld4 r8 = [r33]
nop 0
br.ret.sptk.many b0
.endp one_restrict_pointer#
.align 16
.global two_restrict_pointers#
.proc two_restrict_pointers#
two_restrict_pointers:
.prologue
.body
.mmb
nop 0
ld4 r8 = [r33]
nop 0
.mbb
st4 [r32] = r0
nop 0
br.ret.sptk.many b0
.endp two_restrict_pointers#
.ident "GCC: (GNU) 3.5.0 20040217 (experimental)"
As you can imagine, the scheduler wants to schedule the long latency
load above the store. As you can see, this only happens in the case
of two restrict pointers. I would also like to see it happen in the
case of one restrict pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/14192] Restrict pointers don't help
2004-02-18 13:55 [Bug middle-end/14192] New: Restrict pointers don't help hoogerbrugge at hotmail dot com
` (3 preceding siblings ...)
2004-02-19 14:02 ` hoogerbrugge at hotmail dot com
@ 2004-10-11 10:56 ` giovannibajo at libero dot it
2005-01-23 18:48 ` steven at gcc dot gnu dot org
` (3 subsequent siblings)
8 siblings, 0 replies; 15+ messages in thread
From: giovannibajo at libero dot it @ 2004-10-11 10:56 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From giovannibajo at libero dot it 2004-10-11 10:56 -------
Zack, do you confirm that the semantics of restrict (in C99 and/or GNU C) allow
us to schedule the load before the store even if there is only one restrict
pointer? Otherwise, this bug report is invalid.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |zack at gcc dot gnu dot org,
| |giovannibajo at libero dot
| |it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/14192] Restrict pointers don't help
2004-02-18 13:55 [Bug middle-end/14192] New: Restrict pointers don't help hoogerbrugge at hotmail dot com
` (4 preceding siblings ...)
2004-10-11 10:56 ` giovannibajo at libero dot it
@ 2005-01-23 18:48 ` steven at gcc dot gnu dot org
2005-01-23 18:51 ` steven at gcc dot gnu dot org
` (2 subsequent siblings)
8 siblings, 0 replies; 15+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-01-23 18:48 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steven at gcc dot gnu dot org 2005-01-23 18:48 -------
Zack, Joseph, could one of you comment on Jan's interpretation of
the semantics of restrict?
This restrict keyword keeps coming back to haunt us, bah.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsm28 at gcc dot gnu dot org
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/14192] Restrict pointers don't help
2004-02-18 13:55 [Bug middle-end/14192] New: Restrict pointers don't help hoogerbrugge at hotmail dot com
` (5 preceding siblings ...)
2005-01-23 18:48 ` steven at gcc dot gnu dot org
@ 2005-01-23 18:51 ` steven at gcc dot gnu dot org
2005-01-23 20:59 ` joseph at codesourcery dot com
2005-09-28 5:21 ` ian at airs dot com
8 siblings, 0 replies; 15+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-01-23 18:51 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steven at gcc dot gnu dot org 2005-01-23 18:51 -------
We should probably have a metabug for restrict. We don't take advantage
of the restrict keyword very well either in some (unfortunately proprierty)
benchmark suites.
--
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |14187
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/14192] Restrict pointers don't help
2004-02-18 13:55 [Bug middle-end/14192] New: Restrict pointers don't help hoogerbrugge at hotmail dot com
` (6 preceding siblings ...)
2005-01-23 18:51 ` steven at gcc dot gnu dot org
@ 2005-01-23 20:59 ` joseph at codesourcery dot com
2005-09-28 5:21 ` ian at airs dot com
8 siblings, 0 replies; 15+ messages in thread
From: joseph at codesourcery dot com @ 2005-01-23 20:59 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From joseph at codesourcery dot com 2005-01-23 20:59 -------
Subject: Re: Restrict pointers don't help
On Sun, 23 Jan 2005, steven at gcc dot gnu dot org wrote:
> Zack, Joseph, could one of you comment on Jan's interpretation of
> the semantics of restrict?
6.7.3.1 Formal definition of restrict
[#1] Let D be a declaration of an ordinary identifier that
provides a means of designating an object P as a restrict-
qualified pointer to type T.
[#2] If D appears inside a block and does not have storage
class extern, let B denote the block. If D appears in the
list of parameter declarations of a function definition, let
B denote the associated block. Otherwise, let B denote the
block of main (or the block of whatever function is called
at program startup in a freestanding environment).
I believe this much is straightforward.
[#3] In what follows, a pointer expression E is said to be
based on object P if (at some sequence point in the
execution of B prior to the evaluation of E) modifying P to
point to a copy of the array object into which it formerly
pointed would change the value of E.117) Note that
``based'' is defined only for expressions with pointer
types.
Although things may not be clear in some cases where the representation of
pointers is inspected bitwise, in plausibly optimizable cases I think the
meaning of "based on" is OK.
[#4] During each execution of B, let L be any lvalue that
has &L based on P. If L is used to access the value of the
object X that it designates, and X is also modified (by any
means), then the following requirements apply: T shall not
be const-qualified. Every other lvalue used to access the
value of X shall also have its address based on P. Every
So if something is accessed through a restricted pointer, and it is
modified, all accesses are based on that pointer: all pointer dereferences
not based on that pointer are independent of accesses to that which is
modified. (It is still valid to have two restricted pointers to the same
array of char, one used to modify the odd numbered bytes and one to modify
the even numbered bytes: but a byte accessed through one pointer and
modified can't be accessed through any pointer not based on the restricted
pointer, whether or not that other pointer is restricted.)
access that modifies X shall be considered also to modify P,
for the purposes of this subclause. If P is assigned the
For example, given
int *restrict *restrict p;
int *restrict *restrict q;
with **p modified, *p is deemed modified, so even if q == p you can't then
modify **q as an alias to **p that goes through the same restricted
pointer object *p. But given
int *restrict *p;
int *restrict *q;
(without the second level of "restrict") it is possible that p == q and so
you can modify both **p and **q, as both those expressions involve the
same restricted pointer object *p (where &*p == &*q == p == q).
value of a pointer expression E that is based on another
restricted pointer object P2, associated with block B2, then
either the execution of B2 shall begin before the execution
of B, or the execution of B2 shall end prior to the
assignment. If these requirements are not met, then the
behavior is undefined.
The aliasing information provided by "restrict" only applies during the
execution of the block which contains the declaration providing the
"restrict" information. It is possible to copy the restricted pointer to
an outside non-restricted pointer, and once the block has finished
executing that pointer might freely alias; so that outside pointer, of
similar type but lacking "restrict", can't be treated as completely
interchangable with the inner pointer although it may have the same value.
The restrictions on assignment between restricted pointers reduce the
possible ways in which one restricted pointer might dynamically become
based on another, but I'm not sure exactly what optimizations this is
intended to facilitate. As optimizations don't respect block boundaries,
both the fact that "restrict" only provides aliasing information during
its block's execution and the possibility of restricted pointers becoming
based on other restricted pointers are things to bear in mind.
[#5] Here an execution of B means that portion of the
execution of the program that would correspond to the
lifetime of an object with scalar type and automatic storage
duration associated with B.
[#6] A translator is free to ignore any or all aliasing
implications of uses of restrict.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/14192] Restrict pointers don't help
2004-02-18 13:55 [Bug middle-end/14192] New: Restrict pointers don't help hoogerbrugge at hotmail dot com
` (7 preceding siblings ...)
2005-01-23 20:59 ` joseph at codesourcery dot com
@ 2005-09-28 5:21 ` ian at airs dot com
8 siblings, 0 replies; 15+ messages in thread
From: ian at airs dot com @ 2005-09-28 5:21 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From ian at airs dot com 2005-09-28 05:21 -------
We are not waiting for anything in this bug, as far as I can tell.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |ian at airs dot com
Status|WAITING |NEW
Last reconfirmed|0000-00-00 00:00:00 |2005-09-28 05:21:37
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192
^ permalink raw reply [flat|nested] 15+ messages in thread