We already mention that noalias is modeled after the C99 restrict
qualifier but we did omit one important requirement in the description.
For the restrict guarantees the object affected has to be modified
during the execution of the function, in any way (see 18.104.22.168.4 in ).
There are two reasons we want this restriction as well:
- To match the restrict semantics when we lower it to noalias.
- To allow the reasoning that the object pointed to by a noalias pointer is not modified through means not derived from this pointer. Hence, following the uses of that pointer is sufficient to determine potential modifications.
The discussion on this came up as part of D73428. In that patch the
Attributor is taught to derive noalias for call site arguments based
on alias queries against objects that are accessed in the callee. This
is possible even if the pointer passed at the call site was "not-noalias".
To simplify the logic there *and* to allow the use of noalias as
described in 2) above, it is beneficial to follow the C restrict
semantics in cases where there might be "read-read-aliases". Note that
AliasAnalysis* queries for read only objects already result in
NoAlias even if the pointers might "alias".
- From this point of view our Alias Analysis is basically a Dependence Analysis.