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

[Stepan Dyatkovskiy]

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.