[cfe-dev] [llvm-dev] [RFC] Introducing a byte type to LLVM

[Harald van Dijk via cfe-dev]

On 11/06/2021 01:25, Richard Smith via llvm-dev wrote:
> On Sun, 6 Jun 2021 at 12:15, Nuno Lopes via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> 
>     Of course, let's look at a simple example with GVN:
>     if (p == q) {
>        *(p-1) = 0;
>     }
> 
>     If p/q are integers, then it's perfectly fine to replace p with q or
>     vice-versa inside the 'if'.
> 
> 
> If we start with:
> 
> char a[n];
> char b[n];
> long p = (long)(a+n);
> long q = (long)b;
> if (p == q) {
>     *((char*)p-1) = 0;
> }
> 
> ... what prevents us from observing the same issue?

This is (or at least should be) okay, I think, because p is 
ptrtoint(a+n), q is ptrtoint(b), the store is to inttoptr(p)-1, and we 
should already know not to fold inttoptr(ptrtoint(p)) to p. Per 
https://llvm.org/docs/LangRef.html#pointeraliasing, "A pointer value 
formed by an inttoptr is based on all pointer values that contribute 
(directly or indirectly) to the computation of the pointer’s value." The 
"or indirectly" part of that includes the p == q branch condition.[*] 
This means that (char*)p compares equal to a+n, (char*)q compares equal 
to b, but if p == q, then (char*)p and (char*)q are equivalent and 
either may be used to access a or b.

Cheers,
Harald van Dijk

[*] We have to consider all pointer values that contributed before 
optimisations, which we do not track, so unless that changes and we do 
somehow track it, effectively we have to consider all pointer values 
regardless of whether they contributed to handle the possibility that 
the p == q check may be optimised away.