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

[Stepan Dyatkovskiy]

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