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 <[EMAIL PROTECTED]> 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. For the alias-improvements branch I am going to remove the alias-set based restrict implementation and instead will hopefully end up implementing a points-to based solution annotating SSA_NAME_PTR_INFO and using the oracle for disambiguation. Richard.
