https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120972
--- Comment #7 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. 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?
