Hello all, PR18304 show an example where MemCpyOptimizer can cause pointers to alias. Adding a requirement that the called function does not capture the source pointer fixes the issue but it will also decrease the number of opportunities for the transform. Does this seem like the correct direction for a fix? Will it be too restrictive? Among the regression tests the proposed change causes failures in the following files: LLVM :: Transforms/MemCpyOpt/2008-02-24-MultipleUseofSRet.ll LLVM :: Transforms/MemCpyOpt/2008-03-13-ReturnSlotBitcast.ll LLVM :: Transforms/MemCpyOpt/loadstore-sret.ll LLVM :: Transforms/MemCpyOpt/memcpy.ll LLVM :: Transforms/MemCpyOpt/sret.ll If the solution seems correct my idea is to add the "nocapture" attribute to the functions called in the test files (assuming they don't capture the source pointer) to get the same test behavior as before. Best regards David
David Wiberg wrote:> Hello all, > > PR18304 show an example where MemCpyOptimizer can cause pointers to > alias. Adding a requirement that the called function does not capture > the source pointer fixes the issue but it will also decrease the > number of opportunities for the transform. > > Does this seem like the correct direction for a fix? > Will it be too restrictive?It's the correct direction, and also correctness trumps optimization power so it doesn't matter whether it's too restrictive. The only way we can fold away the memcpy is if both sides promise to not write to it before the other, and if both sides won't look at the pointer address itself. You can use "nocapture" to mean the latter. We can use "readonly" and "readnone" attributes for the former, but I don't think memcpyopt currently makes use of them when they appear on the function. For instance, assuming %p1 points to a copy of what %p2 points to: call @foo(i8* readonly %p1) ;; may capture %p1 but won't write to it. call @bar(i8* nocapture %p2) ;; may modify %p2 but won't compare its address with anything, not even a copy captured by @foo We can still merge %p1 and %p2 if these are the only uses. Nick> Among the regression tests the proposed change causes failures in the > following files: > LLVM :: Transforms/MemCpyOpt/2008-02-24-MultipleUseofSRet.ll > LLVM :: Transforms/MemCpyOpt/2008-03-13-ReturnSlotBitcast.ll > LLVM :: Transforms/MemCpyOpt/loadstore-sret.ll > LLVM :: Transforms/MemCpyOpt/memcpy.ll > LLVM :: Transforms/MemCpyOpt/sret.ll > > If the solution seems correct my idea is to add the "nocapture" > attribute to the functions called in the test files (assuming they > don't capture the source pointer) to get the same test behavior as > before. > > Best regards > David > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Maciej Piechotka
2014-Jun-21 14:54 UTC
[LLVMdev] Aliasing caused by MemCpyOptimizer (PR18304)
On Sun, 2014-06-15 at 13:57 +0200, David Wiberg wrote:> Hello all, > > PR18304 show an example where MemCpyOptimizer can cause pointers to > alias. Adding a requirement that the called function does not capture > the source pointer fixes the issue but it will also decrease the > number of opportunities for the transform. > > Does this seem like the correct direction for a fix? > Will it be too restrictive? > > Among the regression tests the proposed change causes failures in the > following files: > LLVM :: Transforms/MemCpyOpt/2008-02-24-MultipleUseofSRet.ll > LLVM :: Transforms/MemCpyOpt/2008-03-13-ReturnSlotBitcast.ll > LLVM :: Transforms/MemCpyOpt/loadstore-sret.ll > LLVM :: Transforms/MemCpyOpt/memcpy.ll > LLVM :: Transforms/MemCpyOpt/sret.ll > > If the solution seems correct my idea is to add the "nocapture" > attribute to the functions called in the test files (assuming they > don't capture the source pointer) to get the same test behavior as > before. > > Best regards > DavidI'm not sure about LLVM coding/patch standards but I imagine that adding a regression test in the patch might be nice. Best regards -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140621/1afe387e/attachment.sig>