[llvm-commits] Final SwitchInst for PR1255: case-ranges.

Duncan Sands baldrick at free.fr
Mon Jul 23 23:23:21 PDT 2012


Hi Nuno,

On 23/07/12 19:20, Nuno Lopes wrote:
>> (3) storing values.  If there is no default case, then the union of the case
>> sets covers every value.  As Chris pointed out (well, maybe this is not what
>> he pointed out), that means that the end of one range must be the start of
>> another range, so there is no point in storing [Lo, Hi) pairs for each range,
>> you can just store the start point of each range.  In the example from (1),
>> rather than storing <-2, 0> for destA and <1, 2> for destB you can store
>> <-2, 1, 2> and have destA, destB store indices into this.  The complete set
>> of APInt values you would store for the above example is:
>>     -2, 1, 3, 4, 5
>>
>> Of course you would want to store them ordered.  I suggest ordering them as
>> signed numbers.  This isn't the same as considered switch cases to be signed,
>> it is just an internal convenience and ensures that two switch instructions
>> with the same ranges will have exactly the same list of APInt values stored
>> in them.
>
> This is an interesting representation. Of course, we can only make a
> final decision after performing a lot of statistics.
> BTW, for this particular scheme, I believe it would be better to order
> numbers as *unsigned*, since then the creation of ConstantRanges out
> of a number sequence is trivial.

hrm?  It is equally trivial whether they are ordered as signed or unsigned
numbers...

>> Maybe the best thing to do is to only provide users with methods that are
>> agnostic about internal storage.
>
> Yep!
> The usage cases we have right now are, at lest, the following:
>    - Jump threading.  Means we need to replace a destination BB with another BB.

This corresponds to the "intersection" operation I mentioned.

>    - Remove unreachable cases.  Since we proved that a certain range is
> not reachable, we can make removeCase() join the removed range with a
> consecutive one. E.g. removing the case [4,6) in a list with <1, 4, 6,
> 10> can either yield <1, 6, 10> or <1, 4, 10>  (using Duncan's above
> representation).

Yup, this is the "union" operation.

>    - Replace switches with a single destination BB with a jump.  We
> just need to be able to iterate over destination BBs.
>    - Iterate over case ranges + their destination BBs. E.g., for bitcode writer.
>
> And I cannot remember of anything else right now..

Ciao, Duncan.




More information about the llvm-commits mailing list