[llvm-commits] Reworked SwitchInst prototype with case-ranges.

[Stepan Dyatkovskiy]

ping
Stepan Dyatkovskiy wrote:
> Hi Duncan. I'd propose to use "unreacheble" block. I also propose to
> mark ranges with some tombstone marker and skip them in iteration
> cycles. Based on example in previous post, initially we should have next
> collection of numbers:
>
> Format is: [Low, SuccessorIndex]
> [0,  0]
> [5,  1]
> [10, 2]
> [15, 3]
>
> While successors collection contains the next successors:
> [Successor0, Successor1, Successor2, Successor3]
>
> removeRange("[5..10)") will changes these collection with next way:
>
> [0,  0]
> [5,  *Tombstone*]
> [10, 2]
> [15, 3]
>
> [Successor0, *Unreachable*, Successor2, Successor3]
>
> What do you think about it?
>
> It doesn't means that I deny schema with IRBuilder. E.g. if you know
> that most of cases will be removed, of course it is better to rebuild
> the 'switch'.
>
> P.S.: Based on some additional statistics, I found that removeCase is
> used for only ~1.6% of all switches. Though if "remove" operation has a
> place, it removes about ~32% of all cases.
> The link to the statistics post is here:
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/054750.html
>
> -Stepan.
>
> Duncan Sands wrote:
>> Hi Stepan,
>>
>>> One more question. Let assume, default case went away, and we have
>>> next ranges set:
>>> [0..5)   --> Successor0
>>> [5..10)  --> Successor1
>>> [10..15) --> Successor2
>>> [15..0)  --> Successor3
>>>
>>> Remove range [5..10):
>>
>> a "remove" operation doesn't make any sense and shouldn't exist.  All
>> that
>> makes sense is saying: change 5..10 to now go to successorXYZ.  Most
>> of the
>> time the optimizer making the change will know perfectly well where 5..10
>> should go, so no problem.  There is another case though: when the
>> optimizers
>> prove that 5..10 are impossible, i.e. cannot occur.  Then the optimizers
>> should
>> do the optimal thing :)  Which is probably to send 5..10 to the same
>> place as
>> the abutting ranges.  In your example this means either to Successor0 or
>> Successor1.  Probably the best thing to do is to add them to whichever
>> of these
>> has the largest set of values going to it.  In your case they both have 6
>> values going to them.  At this point the optimizers will have to make an
>> arbitrary choice, eg it chooses to send them to Successor0.  An
>> alternative is
>> to allow a destination to be "undef" and send 5..10 to undef.  Or
>> introduce a
>> basic block containing only "unreachable" and send 5..10 there.
>