[PATCH] D52002: Switch optimization for known maximum switch values

[Ayonam Ray via Phabricator via llvm-commits]

ayonam added a comment.

In https://reviews.llvm.org/D52002#1232858, @hans wrote:

> I don't think storing the MaxSwitchValue in the switch instructions itself is the right approach. Generally LLVM doesn't store analysis results in the instructions.
>
> I also don't think the right way to do this is necessarily to change the jump table lowering itself, instead I'd suggest doing it at the IR level:
>
> if we detect that the value range for the switch variable is small enough that adding a few more cases to the switch would cover the range completely, add those cases and mark the default bb unreachable. Then let the lowering code deal with exploiting the unreachable default bb. There is room for improvement there, see "FIXME: Exploit unreachable default more aggressively" in visitSwitch() but we should do that anyway.
>
> What do you think?


Thanks for your comments Hans.

I will move the storing of the MaxSwitchValue to the metadata of the instruction.  I think that is the right place to store these things.

However, I beg to differ on the second point.  If we do the changes in the IR by adding the requisite case statements, it will definitely generate the switch table that we expect to generate.  However, when we mark the default branch as unreachable, the lowering code will redirect the unreachable default to the most popular switch block.  And that would mean that the conditional branch for the default case would still be generated.  Unless we have a way to completely snuff out the default case, which I believe is difficult since there are other parts of the lowering code that have a dependency on the handling of the default case, I do not see how we can do away with the conditional branch for the default case.  Did I miss something there?

Also, when you point to the FIXME in the visitSwitch() do you mean that we can completely do away with an unreachable default case?  I feel theoretically we should be able to.  If there is an unreachable default, then we should be able to jump to the end of the switch block.  But even that would mean a conditional jump to the end of the switch block that would handle the default case.

I feel that the only way we can handle this is during lowering.  That decision about whether to completely skip the branch for the default case is only possible at that level.  Even if we do the creation of the expanded jump table by adding new case statements to the IR, this one thing probably has to be done at the time of lowering only.  Would you have other suggestions to handle this aspect?


Repository:
  rL LLVM

https://reviews.llvm.org/D52002