[LLVMbugs] [Bug 22348] New: Non linear MemoryDependencyAnalysis

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Jan 27 07:17:33 PST 2015


http://llvm.org/bugs/show_bug.cgi?id=22348

            Bug ID: 22348
           Summary: Non linear MemoryDependencyAnalysis
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: bruno.cardoso at gmail.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13740
  --> http://llvm.org/bugs/attachment.cgi?id=13740&action=edit
test case generator

The attached python scripts creates a testcases that look like

  %a0 = alloca i8
  store i8 42, i8* %a0
  %a1 = alloca i8
  store i8 42, i8* %a1
  ...

  %x0 = load i8* %a0
  call void @bar(i8 %x0)
  %x1 = load i8* %a1
  call void @bar(i8 %x1)
  ...

  call void @foo(i8* %a0)
  call void @foo(i8* %a1)

For analyzing each load, alias analysis finds that the pointer is
AliasAnalysis::ModRef. To get better precision we run callCapturesBefore on
each call to see if that call could have written to the memory position.

To implement callCapturesBefore, we need to find if uses of the pointer that
can capture it dominate the call. To do that, we have to walk the basic block
from the start.

One option that might work is to compute a minimal set of instructions that
capture a pointer. Minimal in the sense one does not dominate the other. One
important property of this set is that it would have at most one instruction
per BB.

With that set we can then check if any of those instructions dominate the call.

Another option is to try to speed up dependency computation when both
instructions are in the same BB.

-- 
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/20150127/c648373c/attachment.html>


More information about the llvm-bugs mailing list