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

[Stepan Dyatkovskiy]

Ping.

-Stepan.

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