On Tue, Oct 6, 2020 at 4:03 PM Martin Liška <mli...@suse.cz> wrote: > > 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?
As said I'd have a BB-local pass over BBs recording the index variable and the range covered by the BBs gcond, plus recording how many excess stmts there are for eventual code motion. Only after that BB-local pass start to group BBs in a walk from dominated to dominating BBs looking for common indexes and building a case vector. The main thing is to avoid repeatedly analyzing BBs conditions (so the first pass could be also a on-demand precompute thing) and making the case vector build optimal. > Thanks, > > Martin >
