[LLVMbugs] [Bug 22460] New: Canonicalizing load -> store to use integer type confuses LICM

[bugzilla-daemon at llvm.org]

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

            Bug ID: 22460
           Summary: Canonicalizing load -> store to use integer type
                    confuses LICM
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: michael.m.kuperstein at intel.com
                CC: chandlerc at gmail.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The canonicalization committed in r226781 creates a pattern that confuses LICM.
The minimal reproducer I managed to come up with is below:

target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc"

@in = internal unnamed_addr global i32* null, align 8
@out = internal unnamed_addr global i32* null, align 8

define i64 @bar(i32 %N) {
entry:
  br label %do.body

do.body:                                          
  %i.0 = phi i32 [ 0, %entry ], [ %inc, %l2 ]
  %total = phi i64 [ 0, %entry ], [ %next, %l2]
  %c = icmp eq i32 %N, 6
  br i1 %c, label %l1, label %l2
l1:
  %v = load i32** @in, align 8
  store i32* %v, i32** @out, align 8
  br label %l2
l2:
  %inval = load i32** @in, align 8
  %int = ptrtoint i32* %inval to i64
  %next = add i64 %total, %int
  %inc = add nsw i32 %i.0, 1
  %cmp = icmp slt i32 %inc, %N
  br i1 %cmp, label %do.body, label %do.end

do.end:                                           
  ret i64 %total
}

Running opt -basicaa -gvn -licm produces this:
define i64 @bar(i32 %N) {
entry:
  %c = icmp eq i32 %N, 6
  %v = load i32** @in, align 8
  %inval.pre = load i32** @in, align 8
  br label %do.body

do.body:                                          ; preds = %l2, %entry
  %i.0 = phi i32 [ 0, %entry ], [ %inc, %l2 ]
  %total = phi i64 [ 0, %entry ], [ %next, %l2 ]
  br i1 %c, label %l1, label %do.body.l2_crit_edge

do.body.l2_crit_edge:                             ; preds = %do.body
  br label %l2

l1:                                               ; preds = %do.body
  store i32* %v, i32** @out, align 8
  br label %l2

l2:                                               ; preds =
%do.body.l2_crit_edge, %l1
  %inval = phi i32* [ %inval.pre, %do.body.l2_crit_edge ], [ %v, %l1 ]
  %int = ptrtoint i32* %inval to i64
  %next = add i64 %total, %int
  %inc = add nsw i32 %i.0, 1
  %cmp = icmp slt i32 %inc, %N
  br i1 %cmp, label %do.body, label %do.end

do.end:                                           ; preds = %l2
  %total.lcssa = phi i64 [ %total, %l2 ]
  ret i64 %total.lcssa
}

The load has been hoisted above the loop.
Adding instcombine before gvn gives us:

define i64 @bar(i32 %N) {
entry:
  %c = icmp eq i32 %N, 6
  %inval.pre = load i32** @in, align 8
  br label %do.body

do.body:                                          ; preds = %l2, %entry
  %i.0 = phi i32 [ 0, %entry ], [ %inc, %l2 ]
  %total = phi i64 [ 0, %entry ], [ %next, %l2 ]
  br i1 %c, label %l1, label %do.body.l2_crit_edge

do.body.l2_crit_edge:                             ; preds = %do.body
  br label %l2

l1:                                               ; preds = %do.body
  %v1 = load i64* bitcast (i32** @in to i64*), align 8
  store i64 %v1, i64* bitcast (i32** @out to i64*), align 8
  %0 = inttoptr i64 %v1 to i32*
  br label %l2

l2:                                               ; preds =
%do.body.l2_crit_edge, %l1
  %inval = phi i32* [ %inval.pre, %do.body.l2_crit_edge ], [ %0, %l1 ]
  %int = ptrtoint i32* %inval to i64
  %next = add i64 %total, %int
  %inc = add nsw i32 %i.0, 1
  %cmp = icmp slt i32 %inc, %N
  br i1 %cmp, label %do.body, label %do.end

do.end:                                           ; preds = %l2
  %total.lcssa = phi i64 [ %total, %l2 ]
  ret i64 %total.lcssa
}

-- 
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/20150204/d6acb99e/attachment.html>