[LLVMbugs] [Bug 16397] New: missed optimization in trunc(shufflevector(insertvector))

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Thu Jun 20 21:28:22 PDT 2013


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

            Bug ID: 16397
           Summary: missed optimization in
                    trunc(shufflevector(insertvector))
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu, nrotem at apple.com
    Classification: Unclassified

Examine example 3 from http://blog.regehr.org/archives/320 . Now that we
vectorize this code, we should be able to produce nothing less than what icc
does.

LLVM fails to generate awesome code for this due to extra casts. Consider the
sequence:

  %tmp = trunc i64 %index to i32
  %broadcast.splatinsert6 = insertelement <4 x i32> undef, i32 %tmp, i32 0
  %broadcast.splat7 = shufflevector <4 x i32> %broadcast.splatinsert6, <4 x
i32> undef, <4 x i32> zeroinitializer
  %induction8 = add <4 x i32> %broadcast.splat7, <i32 0, i32 1, i32 2, i32 3>
  %induction9 = add <4 x i32> %broadcast.splat7, <i32 4, i32 5, i32 6, i32 7>
  %tmp1 = trunc <4 x i32> %induction8 to <4 x i8>
  %tmp2 = trunc <4 x i32> %induction9 to <4 x i8>

this can be more straight-forwardly expressed as:

  %tmp = trunc i64 %index to i8
  %broadcast.splatinsert6 = insertelement <4 x i8> undef, i8 %tmp, i32 0
  %broadcast.splat7 = shufflevector <4 x i8> %broadcast.splatinsert6, <4 x i8>
undef, <4 x i32> zeroinitializer
  %tmp1 = add <4 x i8> %broadcast.splat7, <i8 0, i8 1, i8 2, i8 3>
  %tmp2 = add <4 x i8> %broadcast.splat7, <i8 4, i8 5, i8 6, i8 7>

which has dramatic effect on the x86 assembly produced by llc.

Adding this optimization to instcombine seems straight-forward, except that we
need to decide, at IR time, whether it's actually safe to shrink to the smaller
type. (For the non-vector case we assume it always is and let the backend
enlarge it as needed.) Nadav?

-- 
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/20130621/67183f37/attachment.html>


More information about the llvm-bugs mailing list