[llvm-dev] Reducing the number of ptrtoint/inttoptrs that are generated by LLVM

Juneyoung Lee via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 17 23:57:35 PST 2019


Hello Sanjoy,

Yep, combining it with propagateEquality of pointers may raise problem. :\

However I believe propagateEquality should be fixed properly, and adding
psub also suggests a solution for that. :)

It is sound to replace a pointer with another if subtraction of them is 0:

a = malloc()
free(a)
b = malloc() // Assume b == a numerically
if ((psub inbounds a b) == 0) { // a and b are pointing to different
objects, so the comparison becomes poison
  use(a)
}

=>

a = malloc()
free(a)
b = malloc() // Assume b == a numerically
if ((psub inbounds a b) == 0) {
  use(b)
}

Juneyoung Lee

On Fri, Jan 18, 2019 at 7:50 AM Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> On Mon, Jan 14, 2019 at 3:23 AM Juneyoung Lee via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Patch https://reviews.llvm.org/D56598 adds llvm.psub(p1,p2) intrinsic
> function, which subtracts two pointers and returns the difference. Its
> semantic is as follows.
> >
> > If p1 and p2 point to different objects, and neither of them is based on
> a pointer casted from an integer, `llvm.psub(p1, p2)` returns poison. For
> example,
>
> Are you proposing landing this in conjunction with some of the other
> stuff discussed in the twin allocation paper?  Otherwise isn't this
> problematic with propagateEquality of pointers?
>
> a = malloc()
> free(a)
> b = malloc() // Assume b == a numerically
> if (a == b) {
>   print(psub(b, b)) // prints 0
> }
>
> =>
>
> a = malloc()
> free(a)
> b = malloc() // Assume b == a numerically
> if (a == b) {
>   print(psub(a, b)) // prints poison
> }
>
> Though I admit propagateEquality of pointers has many other problems like
> this.
>
>
> -- Sanjoy
>


-- 

Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190118/8acf5329/attachment.html>


More information about the llvm-dev mailing list