[PATCH] D115615: [MemCpyOpt] Make capture check during call slot optimization more precise

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 3 08:14:21 PST 2022


nikic added a comment.

In D115615#3217559 <https://reviews.llvm.org/D115615#3217559>, @reames wrote:

> However, I think I found a counter example to this transform.
>
> Consider the following case:
> %dest = &g
> %src = alloca
> foo(%src)
> memcpy src to dest
>
> foo(i8* %a) {
>
>   if (%a == &g) throw();
>
> }
>
> That is, if we allow foo to capture it's argument, one of the things it's allowed to do is to check the address of address of that argument against an already captured address (such as a global).  In the original program, that comparison will always be false, but if dest is the global, we've changed program behavior.
>
> Do you see something I'm missing which disallows this case?

This is a bit tricky. We do a related check in the code at https://github.com/llvm/llvm-project/blob/4435d1819efec06e11461799fe83d6f148b098f4/llvm/lib/Transforms/Scalar/MemCpyOptimizer.cpp#L966-L975, because generally this transform is already illegal for other reasons if dest may be captured by the call. This is an AA based check though, so a sufficiently smart GlobalsModRef might decide that the call cannot mod/ref the global if the global is only used in a comparison (haven't checked whether it is actually that smart). To be more conservative, I could add a check that the dest is "identified function local" to preclude the possibility that it has already escaped before the function (like a global).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115615/new/

https://reviews.llvm.org/D115615



More information about the llvm-commits mailing list