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

[Duncan Sands]

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.

Ciao, Duncan.

>
> [0..5)   --> Successor0
> [5..10)  --> ?? - which successor we should insert here?
> [10..15) --> Successor2
> [15..0)  --> Successor3
>
> Now all successors has the *same* rights. And we can't redirect holes to any of
> them.