[llvm-dev] [RFC] Introducing a byte type to LLVM
Nicolai Hähnle via llvm-dev
llvm-dev at lists.llvm.org
Tue Jun 22 00:14:11 PDT 2021
On Mon, Jun 21, 2021 at 9:08 PM John McCall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 21 Jun 2021, at 2:15, Juneyoung Lee wrote:
> actually have semantics for pointer castings tailored to LLVM (link
> In this proposal, ptrtoint does not have an escaping side effect; ptrtoint
> and inttoptr are scalar operations.
> inttoptr simply returns a pointer which can access any object.
> Skimming your paper, I can see how this works *except* that I don’t
> see any way not to treat ptrtoint as an escape. And really I think
> you’re already partially acknowledging that, because that’s the only
> real sense of saying that inttoptr(ptrtoint p) can’t be reduced to
> p. If those are really just scalar operations that don’t expose
> p in ways that might be disconnected from the uses of the inttoptr
> then that reduction ought to be safe.
I haven't read the paper yet, but I think the argument is: Assume p was
obtained via an out-of-bounds GEP that happens to point at valid memory
that belongs to a different object than p's provenance. In that case,
dereferencing inttoptr(ptrtoint(p)) is defined behavior ("inttoptr simply
returns a pointer which can access any object") while dereferencing p is UB.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev