[llvm-bugs] [Bug 26429] New: LICM Store promotion when store found in preheader

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26429

            Bug ID: 26429
           Summary: LICM Store promotion when store found in preheader
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: listmail at philipreames.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

When doing store promotion, we have to satisfy a legality constraint which
prevents us from inserting any new stores to locations visible to other threads
along any dynamic path.  Today, we do this by finding a store inside the loop
guaranteed to execute on all paths through the loop.  We could also satisfy
this legality constraint by finding a store immediately before the loop and
removing that one as part of the transformation.  

Motivating example:
int location;
void foo() {
  int start = location;
  for (int i = 0; i < 1000; i++) {
    // Key point is we can't establish the store in the loop to always exit
    if (volatile load) break;
    location = start + i;
  }
}

In general, any store outside the loop which is post-dominated by the loop
header and dominates the loop header without intervening memory access would be
legal, but in practice, we probably want to limit the search to the preheader
and possible one or two immediately preceding blocks.  (This might also be
interesting to express over the newly added MemorySSA form!)

Note that the same argument applies to a store which post-dominates all exits
from the loop.  Without any real evidence, I suspect that case might be more
rare.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160202/0f8799e5/attachment.html>