On 10/6/20 9:47 AM, Richard Biener wrote:
But is it really extensible with the current implementation?  I doubt so.

I must agree with the statement. So let's make the pass properly.
I would need a help with the algorithm where I'm planning to do the following
steps:

1) for each BB ending with a gcond, parse index variable and it's VR;
   I'll support:
   a) index == 123 ([123, 123])
   b) 1 <= index && index <= 9 ([1, 9])
   c) index == 123 || index == 12345 ([123, 123] [12345, 12345])
   d) index != 1 ([1, 1])
   e) index != 1 && index != 5 ([1, 1] [5, 5])

2) switch range edge is identified, e.g. true_edge for 1e, while false_edge for 
1a

3) I want to support forward code hoisting, so for each condition BB we need to 
identify
   if the block contains only stmts without a side-effect

4) we can ignore BBs with condition variables that has small number of potential
   case switches

5) for each condition variable we can iterate bottom up in dominator order and 
try
   to find a BB predecessor chain (in first phase no BB in between such 
"condition" BBs)
   that uses a same condition variable

6) the chain will be converted to a switch statement
7) code hoisting must be done in order to move a gimple statements and fix 
potential
   gphis that can be collapsed

Is it something feasible that can work?
Thanks,

Martin

Reply via email to