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