This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Restrict implementation considered harmful
On Fri, 21 Nov 2008, Richard Guenther wrote:
> On Fri, 21 Nov 2008, Jakub Jelinek wrote:
>
> > On Fri, Nov 21, 2008 at 08:31:18AM -0500, Diego Novillo wrote:
> > > On Fri, Nov 21, 2008 at 06:21, Richard Guenther <rguenther@suse.de> wrote:
> > >
> > > > I think the only reasonable thing to do is to rip out the broken
> > > > restrict pointer handling completely.
> > > >
> > > > Any better ideas?
> > >
> > > I will assume that this program is valid. I am not familiar enough
> > > with the restrict definition, but ISTM that if __restrict implies a
> > > contract not to make the pointers conflict, then this program is
> > > obviously violating it.
> >
> > At least the second testcase in the PR you opened would be easily fixed if
> > we did the same as internal_get_tmp_var does for user VAR_DECLs of restrict
> > pointers from their initializers. Guess something similar would need
> > to be done during inlining for restrict qualified arguments.
>
> And for variables used by insertion in PRE and LIM. And maybe in
> other places, like the vectorizer cases we hit.
>
> > For the first testcase, I'm not sure how the compiler is supposed to find
> > out what other pointer is a restricted pointer based on, when it doesn't
> > have an initializer.
>
> I'm not sure how to read 6.7.3.1/4 for this case (ok, the "Formal
> definition of restrict" is written in a completely confusing manner to
> me). If assigning a restrict based pointer to something uninitialized
> triggers "If P is assigned the value of a pointer expression E that is
> based on another restrict pointer object P2, ... then the behavior is
> undefined" and whatever is this about the blocks B and B2 doesn't hold
> then the first testcase would be undefined. But I think that this
> makes the implementation fragile again as we cannot distinguish
> between invalid transformations keeping the chains not intact and
> initial undefined code.
Btw, the definition of "based on" in 6.7.3.1 seems to make any pointer
P based on another pointer Q if changing Q prior to evaluating
the expression initializing P changes the value of P. Thus it looks
like a pointer P is "based on" a pointer Q if P is value-dependent on Q
which is certainly the case for the first testcase.
Richard.