Re: [PATCH] Add one more pass_convert_switch late.

[Martin Liška <mliska at suse dot cz>]

On 11/19/19 10:25 AM, Richard Biener wrote:
> On Mon, Nov 18, 2019 at 10:17 AM Martin Liška <mliska@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.

I agree with you here. My simple counter example would be a user input
where a switch will be explicitly used :)

> 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.

What we can do is to share decision login in between iftoswitch pass and
cswitch/switch lowering. That way we can convert chains of if statements
that will be interesting for any of the later passes.

One comment here is that 'if-elseif -> gswitch -> lowering to ifs' can
still produce a faster code as be expand smart to a decision tree.

The question still remains what do we want for GCC 10? A selective
iftoswitch conversion?

Thanks,
Martin

> 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