This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Hack to make restrict more useful
On 9/1/07, Mark Mitchell <mark@codesourcery.com> 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 speedy and accurate review!
>
> >> + bool noalias;
> >
> > it's an int.
>
> Doh, fixed.
>
> >> + /* For each incoming pointer argument arg, ARG = ESCAPED_VARS or a
> >> + dummy variable if flag_argument_noalias > 2. */
> >
> > What's this comment for?
>
> Brain leakage. I cut-and-paste that from an older version; sorry, will
> remove.
>
> >> + if (POINTER_TYPE_P (TREE_TYPE (t)) && noalias)
> >
> > noalias > 0 I suppose.
>
> If you like. (Since noalias is never negative, this is logically
> equivalent.) I've made the change.
>
> >> {
> >> varinfo_t vi;
> >> tree heapvar = heapvar_lookup (t);
> >> @@ -4579,7 +4583,7 @@ intra_create_variable_infos (void)
> >> heapvar_insert (t, heapvar);
> >>
> >> ann = get_var_ann (heapvar);
> >> - if (flag_argument_noalias == 1)
> >> + if (flag_argument_noalias <= 1)
> >> ann->noalias_state = NO_ALIAS;
> >> else if (flag_argument_noalias == 2)
> >> ann->noalias_state = NO_ALIAS_GLOBAL;
> >
> > That looks wrong. Shouldn't this just replace flag_argument_noalias
> > for noalias everywhere?
>
> Either will work, but you're right; using noalias is clearer. (In an
> earlier version I'd not organized things in the same way, so that
> wouldn't have worked.) I'll make those changes too.
>
> As you suggest, I'll finish up testing and wait for Danny's comments.
Two comments.
First, the work I have subsumes this, but will be a week or two. Your
work certainly won't hurt in case i get hit by a bus, and i'll happily
just remove it when it becomes obsolete :)
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.
Those only used for loads can alias each other.
This comes from 6.7.3.1 #4, which says "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 *modiïed*
(by any means), ... the following requirements apply:...[part about
not being able to point to same object, basically]"
They even given an example of this (two restricted pointers to arrays
aliasing) happening.
It this an incorrect reading? I'll happily admit that reading
standards makes my brain hurt, it's worse than reading caselaw, so i'd
love to be wrong.
I'd also love to simply ignore this part, because i don't believe
anyone who has actually *used* restrict thinks it means anything other
than "this can't alias my other restrict pointers".
I'm also pretty sure no other compiler implements this restriction
anyway, as it removes a *lot* of useful cases of restrict. We
certainly get it wrong. :)
--Dan