[LLVMbugs] [Bug 24221] New: Unswitching of condition inside case statement of switch

[bugzilla-daemon at llvm.org]

https://llvm.org/bugs/show_bug.cgi?id=24221

            Bug ID: 24221
           Summary: Unswitching of condition inside case statement of
                    switch
           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

Fair warning, this bug is really speculative.  :)

I ran across an interesting snippet of IR copied below.  This structure is
basically selecting between two particular destination blocks based on a
combined predicate on two input variables.  What's interesting is that if
%local_2_ is 0, one of those destinations is always chosen, regardless of the
other input. This reminds me a lot of loop unswitch.  We could consider
interchanging the branch and the switch provided the profiling data indicated
the non-default branches of the switch were dominant.  

define void @test2(i16 %val1, i32 %local_2_) {
bci_84:
  switch i16 %val1, label %bci_149 [
    i16 45, label %merged
    i16 43, label %merged
    i16 58, label %merged
    i16 95, label %merged
    i16 46, label %merged
  ]

bci_149:                                          ; preds = %merged, %bci_84
  tail call void @foo()
  ret void

bci_158:                                          ; preds = %merged
  tail call void @bar()
  ret void

merged:                                           ; preds = %bci_84, %bci_84,
%bci_84, %bci_84, %bci_84
  %.old = icmp eq i32 %local_2_, 0
  br i1 %.old, label %bci_149, label %bci_158
}

This would produce:
define void @test2(i16 %val1, i32 %local_2_) {
bci_84:
  %.old = icmp eq i32 %local_2_, 0
  br i1 %.old, label %bci_149, label %switch

switch:
  switch i16 %val1, label %bci_149 [
    i16 45, label %bci_158
    i16 43, label %bci_158
    i16 58, label %bci_158
    i16 95, label %bci_158
    i16 46, label %bci_158
  ]

bci_149:                                          ; preds = %merged, %bci_84
  tail call void @foo()
  ret void

bci_158:                                          ; preds = %merged
  tail call void @bar()
  ret void
}

Not sure how profitable this would be in general, but it avoids a switch
dispatch along the path where %local_2_ is zero.  If that were the dominant
path, the switch could be placed entirely out of line.

-- 
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/20150722/39054102/attachment.html>