maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/ExecutionEngine/OrcMCJIT/eh-lg-pic.ll

40 lines
1.2 KiB
LLVM
Raw Normal View History

Revert "[OrcMCJIT] Fix test after r335508 causing it to fail on green dragon" This reverts commit a6b904daa1d55e31187c85e5b54ef2ddc37fa713. llvm-svn: 335893
2018-06-29 01:56:27 +08:00
; REQUIRES: cxx-shared-library
[Orc][lli] Add a very simple Orc-based lazy JIT to lli. This ensures that we're building and testing the CompileOnDemand layer, at least in a basic way. Currently x86-64 only, and with limited to no library calls enabled (depending on host platform). Patches welcome. ;) To enable access to the lazy JIT, this patch replaces the '-use-orcmcjit' lli option with a new option: '-jit-kind={ mcjit | orc-mcjit | orc-lazy }'. All regression tests are updated to use the new option, and one trivial test of the new lazy JIT is added. llvm-svn: 233182
2015-03-25 20:11:48 +08:00
; RUN: %lli -jit-kind=orc-mcjit -relocation-model=pic -code-model=large %s
[CMake] Use normalized Windows target triples Changes the default Windows target triple returned by GetHostTriple.cmake from the old environment names (which we wanted to move away from) to newer, normalized ones. This also requires updating all tests to use the new systems names in constraints. Differential Revision: https://reviews.llvm.org/D47381 llvm-svn: 339307
2018-08-09 10:16:18 +08:00
; XFAIL: cygwin, windows-msvc, windows-gnu, mips-, mipsel-, i686, i386, aarch64, arm
[Orc] Regression tests for OrcMCJITReplacement. Duplicated from the MCJIT regression tests. llvm-svn: 227780
2015-02-02 13:04:55 +08:00
declare i8* @__cxa_allocate_exception(i64)
declare void @__cxa_throw(i8*, i8*, i8*)
declare i32 @__gxx_personality_v0(...)
declare void @__cxa_end_catch()
declare i8* @__cxa_begin_catch(i8*)
@_ZTIi = external constant i8*
define void @throwException() {
%exception = tail call i8* @__cxa_allocate_exception(i64 4)
call void @__cxa_throw(i8* %exception, i8* bitcast (i8** @_ZTIi to i8*), i8* null)
unreachable
}
Re-land r335297 "[X86] Implement more of x86-64 large and medium PIC code models" Don't try to generate large PIC code for non-ELF targets. Neither COFF nor MachO have relocations for large position independent code, and users have been using "large PIC" code models to JIT 64-bit code for a while now. With this change, if they are generating ELF code, their JITed code will truly be PIC, but if they target MachO or COFF, it will contain 64-bit immediates that directly reference external symbols. For a JIT, that's perfectly fine. llvm-svn: 337740
2018-07-24 05:14:35 +08:00
; Make an internal function so we exercise R_X86_64_GOTOFF64 relocations.
define internal dso_local void @use_gotoff() {
ret void
}
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
define i32 @main() personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) {
[Orc] Regression tests for OrcMCJITReplacement. Duplicated from the MCJIT regression tests. llvm-svn: 227780
2015-02-02 13:04:55 +08:00
entry:
Re-land r335297 "[X86] Implement more of x86-64 large and medium PIC code models" Don't try to generate large PIC code for non-ELF targets. Neither COFF nor MachO have relocations for large position independent code, and users have been using "large PIC" code models to JIT 64-bit code for a while now. With this change, if they are generating ELF code, their JITed code will truly be PIC, but if they target MachO or COFF, it will contain 64-bit immediates that directly reference external symbols. For a JIT, that's perfectly fine. llvm-svn: 337740
2018-07-24 05:14:35 +08:00
call void @use_gotoff()
[Orc] Regression tests for OrcMCJITReplacement. Duplicated from the MCJIT regression tests. llvm-svn: 227780
2015-02-02 13:04:55 +08:00
invoke void @throwException()
to label %try.cont unwind label %lpad
lpad:
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
%p = landingpad { i8*, i32 }
[Orc] Regression tests for OrcMCJITReplacement. Duplicated from the MCJIT regression tests. llvm-svn: 227780
2015-02-02 13:04:55 +08:00
catch i8* bitcast (i8** @_ZTIi to i8*)
%e = extractvalue { i8*, i32 } %p, 0
call i8* @__cxa_begin_catch(i8* %e)
call void @__cxa_end_catch()
br label %try.cont
try.cont:
ret i32 0
}