https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120972
--- Comment #2 from Feng Xue <fxue at os dot amperecomputing.com> ---
(In reply to Richard Biener from comment #1)
> Yes, it's not possible to implement the standards restrict qualification
> constraints reliably for pointers not in the outermost scope of a function
> and after the compiler was allowed to do CSE or other code transforms.
>
> For simplicity only function parameters (and select "global" cases)
> are handled in the implementation which resides in points-to analysis.
>
> In principle 'restrict' should be handled in the C/C++ language frontends
> instead.
Maybe, I caught your point, w/o front-end scope information, we do not know the
effective lifetime of "__restrict__" pointer merely from def/use chain in the
gimple. An example:
void foo (int *p)
{
int *a_escaped;
{
int * __restrict__ a = ...;
/* no alias between "a" and "p" */
*a = ...;
/* Make "a" escaped from block scope */
a_escaped = a + offset;
}
/* By source-level declaration syntax, "a_escaped" and "p" may be aliased.
But in the gimple, we do not know usage of "a_escaped" does not belongs to
lifetime constrainted by "__restrict__", and could lead to an incorrect
conclusion that "a_escaped" and "p" are alias-free. */
*a_escaped = ...;
...
}
But for the 2nd case, all pointers are defined in the outermost scope of
function. How about an enhancement? Besides parameters, we could also mark all
__restrict__ pointers declared in the outermost scope, and ignore others in any
enclosed scopes, as you said, probably this could be done that at the front-end
stage.
