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: unassignedb...@nondot.org Reporter: listm...@philipreames.com CC: llvmbugs@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.
_______________________________________________ LLVMbugs mailing list LLVMbugs@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs