[LLVMbugs] [Bug 22266] New: [PRE] Failure to lift loop invariant load

[bugzilla-daemon at llvm.org]

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

            Bug ID: 22266
           Summary: [PRE] Failure to lift loop invariant load
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: listmail at philipreames.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Given this test case, our current LoopPRE does not lift the loop invariant load
from %q.  

; RUN: opt -S -basicaa -gvn %s 
; Function Attrs: readonly
declare void @hold(i32) #0

define i32 @test1(i1 %cnd, i32* %p, i32* dereferenceable(8) %q) {
entry:
  br label %header

header:                                           ; preds = %inner, %entry
  br i1 %cnd, label %exit, label %inner

inner:                                            ; preds = %header
  %v2 = load i32* %p
  %v3 = load i32* %q
  %sub = sub i32 %v3, %v2
  call void @hold(i32 %sub)
  br label %header

exit:                                             ; preds = %header
  ret i32 0
}

attributes #0 = { readonly }

This test case is mostly chosen to highlight a weakness with our current
establishment of profitability in PRE.  The LICM pass does get this case, so
the actual test case isn't interesting other than that it sometimes arises due
to pass ordering.

LoadPRE gives up when while trying to find a reasonable merge point because it
encounters a block with multiple successors (i.e. header).  As this case
illustrates, that's clearly not always the best choice.

If we know that the pointer in question is dereferencable, we can relax the
profitability part of the anticipation notion.  Here are a few heuristics that
*might* make sense:
- Skip over all loop exits
- Skip over any split where the other paths are 'cold enough'
- Skip over any split if the load is trivially available along that path (this
happens a lot with multiple latch loops)

Note that this is *only* legal to do for dereferencable pointers.  Lifting the
load of %p without first recognizing that the condition is itself loop
invariant would be illegal.  It could introduce a fault which didn't occur in
the original program.

-- 
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/20150120/09c695a0/attachment.html>