[llvm-dev] [RFC] Introducing a byte type to LLVM
Harald van Dijk via llvm-dev
llvm-dev at lists.llvm.org
Mon Jun 7 10:39:47 PDT 2021
On 04/06/2021 16:24, George Mitenkov via llvm-dev wrote:
> When copying pointers as bytes implicit pointer-to-integer casts
> are avoided.The current setting of performing a memcpy using i8s
> leads to miscompilations (example: bug report 37469
> <https://bugs.llvm.org/show_bug.cgi?id=37469>) and is bad for
> alias analysis.
While trying to understand what exactly is going wrong in this bug I
think I stumbled upon incomplete documentation. At
https://llvm.org/docs/LangRef.html#pointeraliasing it is documented that
* A memory access must be done through a pointer associated with the
* A pointer value is associated with the addresses associated with any
value it is based on.
* A pointer value formed by an instruction is based on another pointer
value the instruction is getelementptr, bitcast, or inttoptr.
What is not mentioned is what a pointer value formed by a load
instruction is based on. If a pointer value formed by a load instruction
is not associated with any address range, then it cannot be used to load
or store /any/ value. Clearly that is not wanted.
If memory is completely untyped, then a load of a pointer value needs to
be equivalent to a load of an integer value followed by inttoptr. In
that model, it is not possible to replace a load of a pointer value by a
previously stored value, it is only possible to replace it by
inttoptr(ptrtoint(previously stored value)). In that model, the problem
is that LLVM does replace a load of a pointer value by a previously
stored value, and the bug can be fixed (at a cost of reduced
optimisations of other code) by making sure to insert ptrtoint and
inttoptr as needed, including for any pointer members of structs etc.
Your proposal is based on an interpretation of the problem using a
memory model where memory is not completely untyped. In your memory
model, what address range is a pointer value that came from a load
instruction associated with?
Harald van Dijk
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev