[PATCH] D60047: [CaptureTracking] Don't let comparisons against null escape inbounds pointers

[Johannes Doerfert via Phabricator via llvm-commits]

jdoerfert added a comment.

Thinking about this further, I guess what you need is:

1. A scope (=function) in which `null` is not a valid pointer (see `NullPointerIsDefined(Function *, unsigned AddrSpace)`)
2. A `dereferenceable_or_null` pointer `Ptr` (see `Value::getPointerDereferenceableBytes`)

Now comparing `Ptr` agains `null` should be `noescape`.

My reasoning (which has to be checked!):

The idea is that you cannot arbitrarily manipulate the pointer while keeping the two properties.
If `Ptr` is `null` to begin with, we are fine (I think).
If it is not, it points to an allocation with extend `[start:end)` where `end - start` equals the dereferenceable bytes.
Due to property 1) we know `null` is not contained in `[start:end)`.
That means we cannot manipulate a pointer such that 2) holds and a `null` comparison would leak information because it always has to be `false`.

Now the `GEP inbounds` case is in my opinion either a special case of the above or not a valid reason for `noescape`. 
I walk you through my thought process (with names for each step so we can discuss):
A) Assuming we have a `GEP inbounds` named `GI` that is compared against `null`.
B) `GI` is either a "valid pointer" into an allocation, a pointer to the end of the allocation (the famous "one past the end"), or `poison` if it is out-of-bounds or the base wasn't an allocation at all.
C) In the `poison` case we could argue that the comparison can be replaced by a constant, e.g., `true`, which eliminates the use and the possibility to escape.
D) In the "valid pointer" case, we know `GI` is `dereferenceable` and the reasoning for such pointer should be applicable.
E) In the "one past the end" case, we can either not justify `noescape` or, what I think, we can argue that the pointer cannot be `null` as the addition "with infinitely precise signed arithmetic" would not overflow. If it is not `null` we can use the final step of the `dereferenceable` reasoning again.

Thoughts?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60047/new/

https://reviews.llvm.org/D60047