https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120972
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Feng Xue from comment #7) > (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. > > I'm working on a patch to pick up and mark restrict pointers in the > outermost scope during build-ssa pass (before other optimizations take > effect). But this would have another complication when function inlining is > invovled. We have to exclude and reset those restrict pointers that have > been marked in the function be inlined, anyway, I think this could be solved > in some way. > > As you said, essentially, it is closely associated with the concept of > declaration scope, and better to handle its semantics in frontend or some > early middle-end pass. So I considered an alternative complete scheme, in > which we could computate memory dependency clique/base for memory accesses > at the very early sate, for example, right after build-ssa pass or a little > later, when scope/block information is still available. But it is very > likely to introduce much more code change than the first enhancement-like > means, and I guess some optimizations on memory accesses (such as memory > combine/remove?) may disturb memory dependency clique/base information, it > tends to be more risky, after all, it did not suffer bugfix torture of time > as the original. > > How do you think about those, any hint or other suggestion? The reason the implementation is restricted as it is and is done as part of pointer analysis is that we can piggy back on the latter for correctness (computing the "derived from" in a conservative manner). Indeed if you move all of this closer to the frontend you have to somehow conservatively perform the analysis of which pointers are dependent according to the definition in the language standard. In principle the encoding of the dependence info is compatible with GENERIC and thus could be done by the frontend itself. If it were simple it would have been already done ;) A trick might be to outline the block that has restrict vars with an initializer.
