[PATCH] D68006: DSE miscompile when store is clobbered across loop iterations

Artur Pilipenko via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 26 15:42:26 PST 2020


apilipenko updated this revision to Diff 246846.
apilipenko added a comment.

Demonstrating an improvement accuracy due to PHI translation turned out to be a bit tricky.

So, it doesn't apply to load-store case as in this case the accessed addresses are the same, so no translation is needed.

In calloc case there are two limitations:

1. Currently we look for stores to pointers with GetUnderlyingObject == calloc. Because GetUnderlyingObject doesn't look through phis we can't handle this case:

    %c = calloc
    %p1 = gep %c, X
    %p2 = gep %c, Y
    ...
  
  label:  
    %p = phi %p1, %p2
    store 0, %p

So we are limited to cases like this:

    %c = calloc
    ...
  
  label:
    %off = phi ...
    %p = gep %c, %off
    store 0, %p



2. Currently I don't analyze the same block with different addresses. If such situation occurs I bail out assuming clobber (the same logic is used in MDA). But because the calloc dominates the store, eventually we'll visit the calloc block. If there are different paths reaching this block with different pointer values we would bail out. So, the example I came up with uses the same pointer on different paths. See test45 and test46 cases.

Essentially I'm using PHITransAddr as a marker that the address needs translation walking up to the predecessor. I don't make real use of the translated address due to lack of path sensitivity.


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

https://reviews.llvm.org/D68006

Files:
  llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp
  llvm/test/Transforms/DeadStoreElimination/simple.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D68006.246846.patch
Type: text/x-patch
Size: 16694 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200226/5932796d/attachment-0001.bin>


More information about the llvm-commits mailing list