Micro-optimization opportunity: Optimizing out default branch from RangeTableSwitchOp

[smarr]

The RangeTableSwitchOp currently always emits a default branch.

This is not always necessary, for instance for bytecode interpreters that do not have a default branch, or for switch statements where a stamp indicates that the default branch is not reachable.

Though, the NodeLIRBuilder assumes for instance that a SwitchNode always has a defaultSuccessor(), which I naively read as the default case for a switch.

The default branch is currently generated unconditionally when emitting the code (AMD64, AArch64).

I would assume it can be omitted in cases where the compiler knows that it's not reachable. For instance based on the stamp of the value over which the switch operates.

On the current bytecode interpreter I looked at, removing the branch "works" and is "safe", however, except for saving the extra 2-3 instructions, it doesn't give a benefit. This might be different for switches in tighter loops though, or once we can generate tighter code for bytecode loops.

/cc @chumer @teshull

[smarr]

@fniephaus Just to note, this isn't solely for the benefit of Truffle interpreters. This is something for any switch/case on the Java level that compiles with the RangeTableSwitchOP strategy.

So, this would also be a benefit for Java compilation in general.

[fniephaus]

@smarr sure, @chumer also knows his way around Java compilation but fair enough.