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

[Stepan Dyatkovskiy]

ping.

Stepan Dyatkovskiy wrote:
> Ping.
>
> -Stepan.
>
> Stepan Dyatkovskiy wrote:
>> ping.
>>
>> -Stepan.
>>
>> Stepan Dyatkovskiy wrote:
>>> 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
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits