[llvm-commits] [LLVM, SwitchInst, case ranges] Auxiliary patch #1

[Stepan Dyatkovskiy]

ping.
-Stepan.

Stepan Dyatkovskiy wrote:
> Hello, Duncan.
>
> Duncan Sands wrote:
>  > I guess Anton can comment on codegen, but the fact that it doesn't make
>  > codegen
>  > harder has nothing to do with increasing the complexity of the
>  > optimizers, since
>  > they work at the IR level. It may be that case ranges allow the
>  > optimizers to
>  > do a better job. It may be that they simplify the optimizers. But it
>  > also may
>  > be the opposite: they might make switches harder to work with and reason
>  > about
>  > for no advantage. Which is it? Do you have an example where case ranges
>  > would
>  > result in better code, or make it easier to produce better code?
>
> I made impact analysis for new case ranges feature.
> 24 out of more than 100 optimizations are affected. 20 of 24 just
> require an integration of a new "case-range" type, i.e. small change of
> code without. The remaining 4 requires some bigger changes. All affected
> optimizers are listed in attached spreadsheet.
>
> Patches that are submitted in this branch are just functionality
> extension for current classes. These patches doesn't brake any of
> existing optimizations and keeps its speed without changes.
>
> Well. Let's enumerate 4 optimizations that should be reworked.
>
> 1. LowerSwitch::Clusterify
>
> This method groups neighbouring cases (by value) that goes to the same
> destination.
>
> For example:
>
> switch i32 %cond, label %default [
> i32 1, label %successorA
> i32 2, label %successorA
> i32 5, label %successorB
> i32 3, label %successorA
> i32 6, label %successorB
> ]
>
> will be grouped to the two clusters:
>
> [[i32 1] .. [i32 3]], label %successorA
> [[i32 5] .. [i32 6]], label %successorB
>
> This method will work faster if clusters will presented explicitly using
> new case ranges feature.
>
> 2. SimplifyCFG.cpp, TurnSwitchRangeIntoICmp (static function)
>
> "Turns a switch that contains only an integer range comparison into a
> sub, an icmp and a branch." (written in method comments). Algorithm that
> determines "solid" case range should be changed.
>
> Now compare two switches (don't look at syntax of second switch, it is
> still a subject of another discussion):
>
> switch i32 %cond, label %default [
> i32 1, label %successorA
> i32 2, label %successorA
> i32 3, label %successorA
> ]
>
> and hypothetical switch:
>
> switch i32 %cond, label %default [
> [[i32 1],[i32 3]], label %successorA ; case range [1..3]
> ]
>
> or even this one:
>
> switch i32 %cond, label %default [
> [[i32 1],[i32 2]], label %successorA ; case range [1..2]
> i32 3, label %successorA ; single case value "3"
> ]
>
> Its obvious that last two switches will be processed faster than the
> first one. We doesn't need to perform analysis for each separated case
> value. We already know - that it is a range.
>
> 3. SimplifyCFG.cpp, EliminateDeadSwitchCases (static function).
>
> Here switch condition is analysed. We try to determine "1" and "0" bits
> that MUST be in condition value. If we found them, then we look at case
> values; if these bits are absent in case value we remove it since it
> will be never equal to condition.
> I need to think more about the ways of case ranges processing here. At
> least we can represent case range as separated values set and apply
> current algorithm to it. It slow down the processing a little bit, but
> the complexity itself will be not increased. I'm sure that there are
> also exists algorithms that allows to eliminate whole case ranges: e.g.
> we can apply current algorithm to high bits that are constant in case
> range.
>
> 4. lib/Transforms/Scalar/LoopUnswitch.cpp (the set of methods).
>
> Just a quote from LoopUnswitch.cpp header
>
> [quote]
> This pass transforms loops that contain branches on loop-invariant
> conditions
> to have multiple loops. For example, it turns the left into the right code.
>
> for (...) if (lic)
> A for (...)
> if (lic) A; B; C
> B else
> C for (...)
> A; C
> [/quote]
>
> I also must think more about case ranges unswithing here.
> By now loops with switch instruction are unswitched value-by-value.
> There is no any case-values clustering before unswitching. For example
> for case range [0..9] we need to run unswitch process 10 times!
> Theoretically, explicitly given case ranges and properly implemented
> unswitching should make this optimization better.
>
> So, as you can see complexity will not changed and even some of
> optimizations will work faster.
>
> Regards,
> Stepan.
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits