[LLVMbugs] [Bug 21797] New: Failure to exploit loop invariant store

[bugzilla-daemon at llvm.org]

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

            Bug ID: 21797
           Summary: Failure to exploit loop invariant store
           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: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

At O3, we are currently failing to exploit the loop invariant store in the
following example:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

declare void @readmem() readonly

; Function Attrs: noreturn
define void @test1(i32* nonnull dereferenceable(4) %p, i32 %v) {
entry:
  br label %for.body

for.body:                                         ; preds = %for.body, %entry
  store i32 %v, i32* %p, align 4
  tail call void @readmem()
  br label %for.body
}

The store is of a loop invariant value to a loop invariant location.  The
address does not alias with any other store in the loop.  We should be able to
lift the store before the loop and execute it exactly once.  

This might be implemented as a special case in LICM, but it could also be
handled by ensuring the loop is unrolled and recognizing that the store still
in the loop has become fully redundant.  I'm unsure which would be easier to
implement and/or more worthwhile.  

I am unsure of the general applicability of this case.  I saw it come up in one
of our internal benchmarks, but only due to another optimizer bug.  I'm filing
it mostly because it seems like an interesting transform to consider.

-- 
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/20141209/56c90424/attachment.html>