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

[Stepan Dyatkovskiy]

Hi Nuno,
 > Uhm, I see. This map can be used when performing backwards range
> analysis (e.g., LazyValueInfo - LVI). Right now LVI has to iterate over
> all switch cases.
> For example, can we have this map being built lazily, and then cached?
> If something changes in the switch, discard the cache.
> I'm just trying to reduce the memory usage, since I'm not sure if this
> map will be used that often.

Not sure about lazy values. It allows to mark Value object as constant, 
nonconstant etc. Switch cases will just APInts, so LVI will not iterate 
over cases in future. In concept almost everywhere, where switch is 
analysed it is modified then, that will cause cache rebuilding. Though I 
to need think more about this idea.

Perhaps we can replace removed BB operand with default BB? Then we can 
store BB-operand-index--to--range-index safely.

>> 3. Relative to defaults. IMHO default BB should be. It will less
>> generic, but more comfortable for usage. We just add some cases and
>> then say: "else do the default". And if user wishes to resolve the
>> default BB he needn't to think "which BB is default here after all?",
>> he just use SI->getDefaultDest().
>> I also think that we should skip default ranges during cases
>> enumeration, since it may confuse the user: e.g. he adds 3 ranges, but
>> got 5, since there is two default ranges between. To me it is just
>> good to mark wasted ranges as defaults. In this case we needn't to
>> rebuild the ranges array, and we keep it without holes.
>> So I propose to keep methods for default case "as is". So only
>> 'switch' internals knows this secret :-)
>
> But with a proper factory in place the user doesn't need to care about
> filling holes, so I think the default case should go away.

 From the factory side - yes. We can implement factory that would 
compile generic ranges set.

But how to be with "read" access? We can got performance regression if 
we will use generic way. Consider next example.
We have 3 ranges: [0..5] [10..15] and [20..25]. All except these ranges 
is default. And we need to process each of them. In generic approach we 
need to process 6 ranges: [0..5], [6..9], [10..15], [16..19], [20..25] 
and [26..-1] // the last one is wrapping.
In old style approach it will 4 ranges only. Internally we use generic 
representation and have 6 ranges too, but Case iterator will skip 
default ranges.

-Stepan.