[PATCH] peephole optimization in switch table lookup: reuse the guarding table comparison if possible

[Hans Wennborg]

Hi Erik,

(Haven't looked much at the patch yet, just thinking about the idea
itself right now.)

On Tue, Nov 18, 2014 at 7:53 AM, Erik Eckstein <eeckstein at apple.com> wrote:
> Hi Hans,
>
> I have another patch for the switch table lookup generation. It tries to reuse the generated compare instruction, if there is a comparison agains the default value after the switch.
>
> Example:
>
> switch (x) {
>   case 0: r = 10; break;
>   case 1: r = 11; break;
>   ...
>   default: r = 0; break; // 0 does not appear in any case value.
> }
> if (r == 0) {
>   do_something;
> }
>
> transforms to:
>
> if (x < table_size) {
>   r = table[x];
> } else {
>   r = 0;
>   do_something;
> }

Interesting. We're basically exploiting that we have extra knowledge
about the relationship between x and r. It would be cool if it was a
bit broader though, e.g. what if it was "if (r < 10)", and that was
only true if we hit the default case in the switch.

My main concern is whether the benefit is worth the complexity this
adds to SwitchToLookupTable (or if that's the right place for it).

I also wonder if we could make it broader, based on control-flow and
value tracking. For example, if we have:

  vars = phi
  if (expr(vars)) {
    do stuff
  }

If we know that expr(vars) is only true for one of the incoming edges
to the phi, could we try to hoist the if-body into that incoming edge?
It seems this would cover your example, and could maybe hit more
cases.

We'd have to be careful not to hoist code into a switch case that
would prevent that switch from being turned into a lookup table. Maybe
we could just run this after SwitchToLookupTable.

Or do we have any passes that keep track of relationships between
variables, like "if x < 10 then r = 42", and exploits that?

I'd be interested to hear if Nick has any thoughts here.

Thanks,
Hans