maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/ARM/jump-table-islands.ll

41 lines
945 B
LLVM
Raw Normal View History

ARM: recommit r237590: allow jump tables to be placed as constant islands. The original version didn't properly account for the base register being modified before the final jump, so caused miscompilations in Chromium and LLVM. I've fixed this and tested with an LLVM self-host (I don't have the means to build & test Chromium). The general idea remains the same: in pathological cases jump tables can be too far away from the instructions referencing them (like other constants) so they need to be movable. Should fix PR23627. llvm-svn: 238680
2015-06-01 03:22:07 +08:00
; RUN: llc -mtriple=armv7-apple-ios8.0 -o - %s | FileCheck %s
%BigInt = type i5500
define %BigInt @test_moved_jumptable(i1 %tst, i32 %sw, %BigInt %l) {
; CHECK-LABEL: test_moved_jumptable:
; CHECK: adr {{r[0-9]+}}, [[JUMP_TABLE:LJTI[0-9]+_[0-9]+]]
; CHECK: b [[SKIP_TABLE:LBB[0-9]+_[0-9]+]]
; CHECK: [[JUMP_TABLE]]:
; CHECK: .data_region jt32
; CHECK: .long LBB{{[0-9]+_[0-9]+}}-[[JUMP_TABLE]]
; CHECK: [[SKIP_TABLE]]:
[ARM] Make -mcpu=generic schedule for an in-order core (Cortex-A8). The benchmarking summarized in http://lists.llvm.org/pipermail/llvm-dev/2017-May/113525.html showed this is beneficial for a wide range of cores. As is to be expected, quite a few small adaptations are needed to the regressions tests, as the difference in scheduling results in: - Quite a few small instruction schedule differences. - A few changes in register allocation decisions caused by different instruction schedules. - A few changes in IfConversion decisions, due to a difference in instruction schedule and/or the estimated cost of a branch mispredict. llvm-svn: 306514
2017-06-28 15:07:03 +08:00
; CHECK: add pc, {{r[0-9]+|lr}}, {{r[0-9]+|lr}}
ARM: recommit r237590: allow jump tables to be placed as constant islands. The original version didn't properly account for the base register being modified before the final jump, so caused miscompilations in Chromium and LLVM. I've fixed this and tested with an LLVM self-host (I don't have the means to build & test Chromium). The general idea remains the same: in pathological cases jump tables can be too far away from the instructions referencing them (like other constants) so they need to be movable. Should fix PR23627. llvm-svn: 238680
2015-06-01 03:22:07 +08:00
br i1 %tst, label %simple, label %complex
simple:
br label %end
complex:
switch i32 %sw, label %simple [ i32 0, label %other
i32 1, label %third
i32 5, label %end
i32 6, label %other ]
third:
ret %BigInt 0
other:
call void @bar()
unreachable
end:
%val = phi %BigInt [ %l, %complex ], [ -1, %simple ]
ret %BigInt %val
}
declare void @bar()