
This PR is to prevent creation of jump tables from switch. The reason is that SPIR-V doesn't know how to lower jump tables, and a sequence of commands that IRTranslator generates for switch via jump tables breaks SPIR-V Backend code generation with complains to G_BRJT. The next example is the shortest code to break SPIR-V Backend code generation in this way: ``` target datalayout = "e-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-n8:16:32:64" target triple = "spir64-unknown-unknown" define spir_func void @foo(i32 noundef %val) { entry: switch i32 %val, label %sw.epilog [ i32 0, label %sw.bb i32 1, label %sw.bb2 i32 2, label %sw.bb3 i32 3, label %sw.bb4 ] sw.bb: br label %sw.epilog sw.bb2: br label %sw.epilog sw.bb3: br label %sw.epilog sw.bb4: br label %sw.epilog sw.epilog: ret void } ``` To resolve the issue we set a high lower limit for number of blocks in a jump table via getMinimumJumpTableEntries() and prevent undesirable (or rather unsupported at the moment) path of code generation.
31 lines
813 B
LLVM
31 lines
813 B
LLVM
; The test is to check that jump tables are not generated from switch
|
|
|
|
; RUN: llc -O0 -mtriple=spirv32-unknown-unknown %s -o - | FileCheck %s
|
|
; RUN: %if spirv-tools %{ llc -O0 -mtriple=spirv64-unknown-unknown %s -o - -filetype=obj | spirv-val %}
|
|
|
|
; CHECK: OpSwitch %[[#]] %[[Label:]]
|
|
; CHECK-4: OpBranch %[[Label]]
|
|
|
|
target datalayout = "e-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-n8:16:32:64"
|
|
target triple = "spir64-unknown-unknown"
|
|
|
|
define spir_func void @foo(i32 noundef %val) {
|
|
entry:
|
|
switch i32 %val, label %sw.epilog [
|
|
i32 0, label %sw.bb
|
|
i32 1, label %sw.bb2
|
|
i32 2, label %sw.bb3
|
|
i32 3, label %sw.bb4
|
|
]
|
|
sw.bb:
|
|
br label %sw.epilog
|
|
sw.bb2:
|
|
br label %sw.epilog
|
|
sw.bb3:
|
|
br label %sw.epilog
|
|
sw.bb4:
|
|
br label %sw.epilog
|
|
sw.epilog:
|
|
ret void
|
|
}
|