rjmccall added a comment. In D75285#1903284 <https://reviews.llvm.org/D75285#1903284>, @yaxunl wrote:
> In D75285#1902835 <https://reviews.llvm.org/D75285#1902835>, > @jeroen.dobbelaere wrote: > > > In D75285#1902788 <https://reviews.llvm.org/D75285#1902788>, @Anastasia > > wrote: > > > > > In D75285#1896610 <https://reviews.llvm.org/D75285#1896610>, @rjmccall > > > wrote: > > > > > > > Are you sure `restrict` alone isn't good enough? It doesn't directly > > > > tell you that the memory is invariant, but it's usually simple to prove > > > > that the memory isn't modified within the `restrict` scope, which might > > > > be sufficient. > > > > > > > > > Do you mean to prove in analysis passes? Should we emit some sort of > > > hints from the frontend to indicate what to look for? > > > > > > Not sure what you mean with 'hints from the frontend', but D68484 > > <https://reviews.llvm.org/D68484> (and later) contain a significant > > improvement to clang's handling of restrict. That could make the restrict > > path feasible (if that would support the actual use case). > > > I think there are cases that noalias is not sufficient to prove invariance. > For example, a global variable, even if we mark it as restrict and we do not > modify it in a function, the compiler is still not sure it is invariant in > that function, since it may be modified by another thread. In this case, if a > user knows that it is invariant in that function, he would just want to mark > it as `__invariant__` or `__immutable__`. That is not true for two reasons: first, `restrict` guarantees that the variable is not accessed through any non-derived l-value within its scope, and that would certainly include from other threads; and second, it is undefined behavior for two threads to access the same object without synchronizing anyway (unless they're both just reading from it). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75285/new/ https://reviews.llvm.org/D75285 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
