Re: RFC: Hack to make restrict more useful

On 9/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On 9/3/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > > On 9/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > > On 9/2/07, Paul Brook <[EMAIL PROTECTED]> wrote: > > > > > > That said, second, my understanding of restrict, from reading the

Re: RFC: Hack to make restrict more useful

On 9/3/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > On 9/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > On 9/2/07, Paul Brook <[EMAIL PROTECTED]> wrote: > > > > > That said, second, my understanding of restrict, from reading the c99 > > > > > standard, is that it is perfectly valid for res

Re: RFC: Hack to make restrict more useful

Mark Mitchell wrote: > Joseph S. Myers wrote: > >> The rules that unmodified memory may alias were a deliberate change in the >> FDIS relative to the previous public draft; see >> : > > That explains why I had no memory of this, despite

Re: RFC: Hack to make restrict more useful

> In any case, I guess we should consider my patch withdrawn. Although, > if the new meaning of "restrict" matches standard Fortran semantics, > then our Fortran handling must be wrong, since all my patch did was make > us match our current Fortran semantics. In Fortran the pointers are not expos

Re: RFC: Hack to make restrict more useful

Joseph S. Myers wrote: > The rules that unmodified memory may alias were a deliberate change in the > FDIS relative to the previous public draft; see > : That explains why I had no memory of this, despite having researched "restrict" pre

Re: RFC: Hack to make restrict more useful

On Sun, 2 Sep 2007, Mark Mitchell wrote: > Daniel Berlin wrote: > > > Again, I'd love to just ignore this and say "we don't care". > > Ugh. I think you're right that the standard says that we only get to > assume non-aliasing when the pointed-to memory is modified, so > all-parameters-restrict

Re: RFC: Hack to make restrict more useful

On 9/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On 9/2/07, Paul Brook <[EMAIL PROTECTED]> wrote: > > > > That said, second, my understanding of restrict, from reading the c99 > > > > standard, is that it is perfectly valid for restrict pointers to alias > > > > each other during *loads*.. IE

Re: RFC: Hack to make restrict more useful

Daniel Berlin wrote: > Again, I'd love to just ignore this and say "we don't care". Ugh. I think you're right that the standard says that we only get to assume non-aliasing when the pointed-to memory is modified, so all-parameters-restrict is actually weaker than -fargument-noalias. How unfortu

Re: RFC: Hack to make restrict more useful

On 9/2/07, Paul Brook <[EMAIL PROTECTED]> wrote: > > > That said, second, my understanding of restrict, from reading the c99 > > > standard, is that it is perfectly valid for restrict pointers to alias > > > each other during *loads*.. IE you can guarantee any restricted > > > pointer that is stor

Re: RFC: Hack to make restrict more useful

> > That said, second, my understanding of restrict, from reading the c99 > > standard, is that it is perfectly valid for restrict pointers to alias > > each other during *loads*.. IE you can guarantee any restricted > > pointer that is stored into can't alias the other restricted pointers. > > T

Re: RFC: Hack to make restrict more useful

On 9/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > That said, second, my understanding of restrict, from reading the c99 > standard, is that it is perfectly valid for restrict pointers to alias > each other during *loads*.. IE you can guarantee any restricted > pointer that is stored into can

Re: RFC: Hack to make restrict more useful

On 9/1/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > >> OK, great. Here's a draft patch for the trick; this works on the test > >> case I had, and I'll be testing it now. If it passes testing, and I add > >> testcases, does this look OK to you? > > Thanks for the spee

Re: RFC: Hack to make restrict more useful

On 9/1/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > >> I fully concede that my trick isn't a general solution to making full > >> use of restrict. But, given that I think it'll take about 20-50 lines > >> of code, and that it will get a lot of the common cases, I thin

Re: RFC: Hack to make restrict more useful

Richard Guenther wrote: >> OK, great. Here's a draft patch for the trick; this works on the test >> case I had, and I'll be testing it now. If it passes testing, and I add >> testcases, does this look OK to you? Thanks for the speedy and accurate review! >> + bool noalias; > > it's an int.

Re: RFC: Hack to make restrict more useful

Richard Guenther wrote: >> I fully concede that my trick isn't a general solution to making full >> use of restrict. But, given that I think it'll take about 20-50 lines >> of code, and that it will get a lot of the common cases, I think it's >> worth it. Do you agree? > > Yes, I agree. I just

Re: RFC: Hack to make restrict more useful

On 9/1/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > >> I have a prototype hack which changes checks of flag_argument_noalias != > >> 0 to also check for the presence of "restrict" on all pointer arguments. > >> This fixes the test case, modulo a C front-end bug which

Re: RFC: Hack to make restrict more useful

Richard Guenther wrote: >> I have a prototype hack which changes checks of flag_argument_noalias != >> 0 to also check for the presence of "restrict" on all pointer arguments. >> This fixes the test case, modulo a C front-end bug which Joseph has >> volunteered to fix. > AFAIK Danny had been "fi

Re: RFC: Hack to make restrict more useful

On 9/1/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > This bug: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33272 > > is about a situation in which -fargument-noalias works better than > putting "restrict" on all pointer arguments to a function, even though > that should be logically equivalent