[llvm] [SimplifyCFG] Find the smallest table considering overflow in `switchToLookupTable` (PR #67885)

via llvm-commits llvm-commits at lists.llvm.org
Sat Sep 30 21:02:30 PDT 2023


================
@@ -9,11 +9,17 @@ target triple = "x86_64-apple-darwin12.0.0"
 define i64 @test(i3 %arg) {
 ; CHECK-LABEL: @test(
 ; CHECK-NEXT:  entry:
-; CHECK-NEXT:    [[SWITCH_TABLEIDX:%.*]] = sub i3 [[ARG:%.*]], -4
+; CHECK-NEXT:    [[SWITCH_TABLEIDX:%.*]] = sub i3 [[ARG:%.*]], 1
+; CHECK-NEXT:    [[TMP0:%.*]] = icmp ult i3 [[SWITCH_TABLEIDX]], -2
+; CHECK-NEXT:    br i1 [[TMP0]], label [[SWITCH_LOOKUP:%.*]], label [[DEFAULT:%.*]]
----------------
DianQK wrote:

Maybe. But I think it could also be a lucky result. We found the smallest jump table. The GEP has changed from `[8 x i64]` to `[6 x i64]`.

> `@f_min_max_2`, `@f_min_max`, `@test`, and `@coveredswitch_test` look to become worse. But their table size did get smaller.
I rechecked `@f_min_max_2`, `@f_min_max` and `@test`. They become from `table with holes` to `table without holes`. It's a "perfect" table? 
I've also found that they **luckily** have a max and min value. Then we created a cover table.
**If we want to deal with this situation, maybe we should add a condition to extend to a cover table.**
`@coveredswitch_test` also luckily have a max and min value.
>From https://reviews.llvm.org/D156612#4585083.

https://github.com/llvm/llvm-project/pull/67885


More information about the llvm-commits mailing list