This patch makes shrinking switch conditions less aggressive which was introduced by https://reviews.llvm.org/rL274233.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Transforms/InstCombine/InstructionCombining.cpp | ||
---|---|---|
2485–2486 | The comments here and in the beginning of the test file say the same thing. |
lib/Transforms/InstCombine/InstructionCombining.cpp | ||
---|---|---|
2485–2486 | Okay, makes sense i guess. |
Please do reference the backend bug№ in the comments.
test/Transforms/InstCombine/narrow-switch.ll | ||
---|---|---|
6–7 | Here too. |
To provide more background/motivation for why I don't think we will solve the underlying problem soon, we can fork this example into its own bug:
https://bugs.llvm.org/show_bug.cgi?id=29009#c4
I said that was an instcombine opportunity in that bug comment, but that was a mistake. It probably requires a GVN-level-of-complexity to see that kind of equivalence between the 2 different-sized masked values. But AFAICT, neither -gvn nor -newgvn optimizes that today (so we should file a 2nd bug to track that as an IR opportunity).
I'm not sure where/how we would catch that in the backend, but that's the kind of code we would see after legalization of non-power-of-2 types.
So that's the reason I think we're justified in limiting this transform with shouldChangeType(). In an ideal world, we could let instcombine go wild with illegal types, but as this example shows, getting optimal codegen from that is likely difficult (and it might not be handled well by other IR passes too), so that's why instcombine has this limitation.
Looks good.
lib/Transforms/InstCombine/InstructionCombining.cpp | ||
---|---|---|
2485–2486 | Minor: when you fix the inline comment, please do mark it as fixed (the checkbox -------------------------------------------^) |
Bugs filed as a result of this patch:
https://bugs.llvm.org/show_bug.cgi?id=39569
https://bugs.llvm.org/show_bug.cgi?id=39578
The comments here and in the beginning of the test file say the same thing.
I remember there were a few mails about this on the mailing list.
Were you able to come to an conclusion that this is *certainly* not a backend problem?