<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">The purpose of an example is to make an assumption about what IR we have, and to show that it becomes wrong after optimization. I am not sure I get your comment here.<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Same here, by just looking at the IR code here, I don't think you can<br>really be sure what the type of the thing being copied is.</blockquote><div>That is exactly the point. We do not know what type we are copying - it may be an integer, or it may be a pointer. Importantly, we can see that the ptr2int instruction disappeared, and the optimized code returning the integer actually can escape the pointer. Using a byte type instead of i64 removes implicit pointer casts and therefore helps AA to catch this case.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">One can do bitcasts etc, to obscure the actual type of the bytes being copied.<br>In both those examples, 8 bytes are copied, and the same value is<br>returned. So the end program will function the same when run.<br>Essentially, there is not enough information in the above code to<br>determine if the 8 bytes copied are part of a pointer or not.<br>For AA analysis, I would say, more information is needed.</blockquote><div>This is just an example of a wrong optimization. It is important because bugs like this appear partially because of this exact optimization:</div><div><a href="https://bugs.llvm.org/show_bug.cgi?id=37469">https://bugs.llvm.org/show_bug.cgi?id=37469</a></div><div>The mecpy is replaced with load/store pairs and store forwarding happens incorrectly. I haven't shown it in full, and hence there may be a bit of confusion. I am happy to elaborate more if this is still unclear!</div><div><br></div><div>Thanks,</div><div>George</div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 7, 2021 at 2:58 PM James Courtier-Dutton <<a href="mailto:james.dutton@gmail.com" target="_blank">james.dutton@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Fri, 4 Jun 2021 at 17:35, George Mitenkov via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi Johannes,<br>
><br>
> Sure! The underlying problem is that raw-memory access handlers are treated<br>
> as integers, while they are not really integers. Especially std::byte that specifically<br>
> states that it has raw-memory access semantics. This semantic mismatch can make<br>
> AA wrong and a pointer to escape.<br>
><br>
> Consider the following LLVM IR that copies a pointer:<br>
You are making an assumption here. By just looking at the IR code<br>
here, I don't think you can really be<br>
sure what the type of the thing being copied is.<br>
> %src8 = bitcast i8** %src to i8*<br>
> %dst8 = bitcast i8** %dst to i8*<br>
> call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dst8, i8* %src8, i32 8, i1 false)<br>
> %load = load i8*, i8** %dst<br>
> %addr = ptrtoint i8* %load to i64<br>
> ret i64 %addr<br>
><br>
> If we optimize the call to memcpy, then the IR becomes<br>
Same here, by just looking at the IR code here, I don't think you can<br>
really be sure what the type of the thing being copied is.<br>
> %src64 = bitcast i8** %src to i64*<br>
> %dst64 = bitcast i8** %dst to i64*<br>
> %addr = load i64, i64* %src64, align 1<br>
> store i64 %addr, i64* %dst64, align 1<br>
> ret i64 %addr<br>
><br>
<br>
One can do bitcasts etc, to obscure the actual type of the bytes being copied.<br>
In both those examples, 8 bytes are copied, and the same value is<br>
returned. So the end program will function the same when run.<br>
Essentially, there is not enough information in the above code to<br>
determine if the 8 bytes copied are part of a pointer or not.<br>
For AA analysis, I would say, more information is needed.<br>
<br>
One can only really be sure what type those bytes are, and that they<br>
are a pointer when they are actually used as a pointer argument to a<br>
LOAD or STORE.<br>
There are some other operations that can also be used to infer whether<br>
it is a pointer or not, but the LOAD/STORE is the simplest example.<br>
<br>
Kind Regards<br>
<br>
James<br>
</blockquote></div>