On Mon, Nov 18, 2019 at 10:17 AM Martin Liška <mli...@suse.cz> wrote: > > On 11/14/19 1:15 PM, Richard Biener wrote: > > Hmm. I was thinking of moving the pass instead of adding another one. > > What's the reason to run switch-conversion during early optimization again? > > I'm adding CC, as he's the author of cswitch pass and he probably knows > more about the pass placement. But I bet early conversion to array access > rapidly simplifies CFG and other passes can benefit from that. > > > > > But then it's probably not too bad... (and somehow I'd still like to see > > switch-conversion, switch lowering and if-to-switch be "integrated" > > somehow, analyzing the IL and then outputting optimized if/switch > > according to the same cost metric). > > Well, my intuition is that gswitch statement is a canonical representation > of a switch. And so that one wants to have if-to-switch early in the pipeline > and switch lowering very late?
Just to throw in a tiny thing here - while a switch seems a natural canonical representation it is actually a poor one for most GCC passes since they're going to give up on switches and it's CFG complexity. GCCs switch representation also isn't exactly good (remember all that label lookup stuff you have to do). Switches are a quite high-level representation and to me only "good" if we are actually going to emit a jump-table. Given converting a series of ifs to a switch is "hard" (the opposite is easy) going for a switch early (before CFG transforms mess up things too much) kind-of makes sense, but lowering back non-jump table ones soon is equally important. That's of course all unrelated to adding another switch-conversion pass. (and yes, switch-converted IL is more friendly than a switch) Richard. > Martin >
