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

[James Courtier-Dutton via llvm-dev]

On Fri, 4 Jun 2021 at 17:35, George Mitenkov via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>
> Hi Johannes,
>
> Sure! The underlying problem is that raw-memory access handlers are treated
> as integers, while they are not really integers. Especially std::byte that specifically
> states that it has raw-memory access semantics. This semantic mismatch can make
> AA wrong and a pointer to escape.
>
> Consider the following LLVM IR that copies a pointer:
You are making an assumption here. By just looking at the IR code
here, I don't think you can really be
sure what the type of the thing being copied is.
> %src8 = bitcast i8** %src to i8*
> %dst8 = bitcast i8** %dst to i8*
> call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dst8, i8* %src8, i32 8, i1 false)
> %load = load i8*, i8** %dst
> %addr = ptrtoint i8* %load to i64
> ret i64 %addr
>
> If we optimize the call to memcpy, then the IR becomes
Same here, by just looking at the IR code here, I don't think you can
really be sure what the type of the thing being copied is.
> %src64 = bitcast i8** %src to i64*
> %dst64 = bitcast i8** %dst to i64*
> %addr = load i64, i64* %src64, align 1
> store i64 %addr, i64* %dst64, align 1
> ret i64 %addr
>

One can do bitcasts etc, to obscure the actual type of the bytes being copied.
In both those examples, 8 bytes are copied, and the same value is
returned. So the end program will function the same when run.
Essentially, there is not enough information in the above code to
determine if the 8 bytes copied are part of a pointer or not.
For AA analysis, I would say, more information is needed.

One can only really be sure what type those bytes are, and that they
are a pointer when they are actually used as a pointer argument to a
LOAD or STORE.
There are some other operations that can also be used to infer whether
it is a pointer or not, but the LOAD/STORE is the simplest example.

Kind Regards

James