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

[Harald van Dijk via cfe-dev]

Hi,

On 04/06/2021 16:24, George Mitenkov via llvm-dev wrote:
>
> 2.
>
>     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
    address range.
  * 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?

Cheers,
Harald van Dijk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210607/997e13fa/attachment.html>