summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine
Commit message (Collapse)AuthorAgeFilesLines
...
* Support X86_64_GOTLoad relocations in RuntimeDyldMachO by treating them theLang Hames2013-08-151-4/+4
| | | | | | | | | | | | | | | | same way as X86_64_GOT relocations. The 'Load' part of GOTLoad is just an optimization hint for the linker anyway, and can be safely ignored. This patch also fixes some minor issues with the relocations introduced while processing an X86_64_GOT[Load]: the addend for the GOT entry should always be zero, and the addend for the replacement relocation at the original offset should be the same as the addend of the relocation being replaced. I haven't come up with a good way of testing this yet, but I'm working on it. This fixes <rdar://problem/14651564>. llvm-svn: 188499
* Optimistically ignore scattered relocations in MachO in RuntimeDyld. ThisLang Hames2013-08-091-0/+10
| | | | | | | | un-breaks simple use cases while I work on more general support. <rdar://problem/14487667> llvm-svn: 188044
* [Object] Split the ELF interface into 3 parts.Michael J. Spencer2013-08-081-4/+3
| | | | | | | | * ELFTypes.h contains template magic for defining types based on endianess, size, and alignment. * ELFFile.h defines the ELFFile class which provides low level ELF specific access. * ELFObjectFile.h contains ELFObjectFile which uses ELFFile to implement the ObjectFile interface. llvm-svn: 188022
* LLVM Interpreter: This patch implements vector support for cast operations ↵Elena Demikhovsky2013-08-051-77/+414
| | | | | | | | | | (zext, sext, uitofp, sitofp, trunc, fpext, fptosi, fptrunc, bitcast) and shift operations (shl, ashr, lshr) for integer and floating point data types. Added tests. Done by Yuri Veselov (mailto:Yuri.Veselov@intel.com). llvm-svn: 187724
* [PowerPC] Support powerpc64le as a syntax-checking target.Bill Schmidt2013-07-263-4/+5
| | | | | | | | | | | | | | | | | | | | | | | This patch provides basic support for powerpc64le as an LLVM target. However, use of this target will not actually generate little-endian code. Instead, use of the target will cause the correct little-endian built-in defines to be generated, so that code that tests for __LITTLE_ENDIAN__, for example, will be correctly parsed for syntax-only testing. Code generation will otherwise be the same as powerpc64 (big-endian), for now. The patch leaves open the possibility of creating a little-endian PowerPC64 back end, but there is no immediate intent to create such a thing. The LLVM portions of this patch simply add ppc64le coverage everywhere that ppc64 coverage currently exists. There is nothing of any import worth testing until such time as little-endian code generation is implemented. In the corresponding Clang patch, there is a new test case variant to ensure that correct built-in defines for little-endian code are generated. llvm-svn: 187179
* AArch64: don't mask off shift bits when processing JIT relocations.Tim Northover2013-07-251-4/+4
| | | | | | | This should actually make the MCJIT tests pass again on AArch64. I don't know how I missed their failure before. llvm-svn: 187120
* [mips] Use pristine object file while processing relocations.Akira Hatanaka2013-07-241-7/+20
| | | | | | | | | | | | | | | | | | | Similar to ARM change r182800, dynamic linker will read bits/addends from the original object rather than from the object that might have been patched previously. For the purpose of relocations for MCJIT stubs on MIPS, we internally use otherwise unused MIPS relocations. The change also enables MCJIT unit tests for MIPS (EL/BE), and the following two tests now pass: - MCJITTest.return_global and - MCJITTest.multiple_functions. These issues have been tracked as Bug 16250. Patch by Petar Jovanovic. llvm-svn: 187019
* Use SmallVectorImpl::iterator/const_iterator instead of SmallVector to avoid ↵Craig Topper2013-07-041-1/+1
| | | | | | specifying the vector size. llvm-svn: 185606
* Fixed alignment of code sections in the JIT mode. Added a test to the ↵Elena Demikhovsky2013-07-021-2/+7
| | | | | | JITMemoryManager. llvm-svn: 185421
* AArch64: correct CodeGen of MOVZ/MOVK combinations.Tim Northover2013-07-011-7/+8
| | | | | | | | | | | | According to the AArch64 ELF specification (4.6.8), it's the assembler's responsibility to make sure the shift amount is correct in relocated MOVZ/MOVK instructions. This wasn't being obeyed by either the MCJIT CodeGen or RuntimeDyldELF (which happened to work out well for JIT tests). This commit should make us compliant in this area. llvm-svn: 185360
* Revising the MCJIT ObjectCache interface to allow subclasses to avoid ↵Andrew Kaylor2013-06-281-1/+1
| | | | | | retaining references to returned objects llvm-svn: 185221
* Basic support for parsing Mach-O universal binaries in LLVMObject libraryAlexey Samsonov2013-06-181-0/+1
| | | | llvm-svn: 184191
* Enable FastISel on ARM for Linux and NaCl, not MCJITJF Bastien2013-06-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a resubmit of r182877, which was reverted because it broken MCJIT tests on ARM. The patch leaves MCJIT on ARM as it was before: only enabled for iOS. I've CC'ed people from the original review and revert. FastISel was only enabled for iOS ARM and Thumb2, this patch enables it for ARM (not Thumb2) on Linux and NaCl, but not MCJIT. Thumb2 support needs a bit more work, mainly around register class restrictions. The patch punts to SelectionDAG when doing TLS relocation on non-Darwin targets. I will fix this and other FastISel-to-SelectionDAG failures in a separate patch. The patch also forces FastISel to retain frame pointers: iOS always keeps them for backtracking (so emitted code won't change because of this), but Linux was getting much worse code that was incorrect when using big frames (such as test-suite's lencod). I'll also fix this in a later patch, it will probably require a peephole so that FastISel doesn't rematerialize frame pointers back-to-back. The test changes are straightforward, similar to: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130513/174279.html They also add a vararg test that got dropped in that change. I ran all of lnt test-suite on A15 hardware with --optimize-option=-O0 and all the tests pass. All the tests also pass on x86 make check-all. I also re-ran the check-all tests that failed on ARM, and they all seem to pass. llvm-svn: 183966
* Convert another use of sys::identifyFileType.Rafael Espindola2013-06-111-26/+28
| | | | | | No functionality change. llvm-svn: 183758
* Pass a StringRef to sys::identifyFileType.Rafael Espindola2013-06-101-3/+1
| | | | llvm-svn: 183669
* Handle (at least don't crash on) relocations with no symbols.Rafael Espindola2013-06-051-6/+11
| | | | | | Should fix the MCJIT tests on PPC. llvm-svn: 183288
* Handle relocations that don't point to symbols.Rafael Espindola2013-06-052-11/+8
| | | | | | | | In ELF (as in MachO), not all relocations point to symbols. Represent this properly by using a symbol_iterator instead of a SymbolRef. Update llvm-readobj ELF's dumper to handle relocatios without symbols. llvm-svn: 183284
* Preserve const correctness.Benjamin Kramer2013-06-041-3/+3
| | | | | | GCC complains about casting away const. llvm-svn: 183216
* Update RuntimeDyldELF::findOPDEntrySection the new relocation iterators.Rafael Espindola2013-06-031-3/+7
| | | | | | | This was missing from r182908. I didn't noticed it at the time because the MCJIT tests were disabled when building with cmake on ppc64 (which I fixed in r183143). llvm-svn: 183147
* Change how we iterate over relocations on ELF.Rafael Espindola2013-05-301-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | For COFF and MachO, sections semantically have relocations that apply to them. That is not the case on ELF. In relocatable objects (.o), a section with relocations in ELF has offsets to another section where the relocations should be applied. In dynamic objects and executables, relocations don't have an offset, they have a virtual address. The section sh_info may or may not point to another section, but that is not actually used for resolving the relocations. This patch exposes that in the ObjectFile API. It has the following advantages: * Most (all?) clients can handle this more efficiently. They will normally walk all relocations, so doing an effort to iterate in a particular order doesn't save time. * llvm-readobj now prints relocations in the same way the native readelf does. * probably most important, relocations that don't point to any section are now visible. This is the case of relocations in the rela.dyn section. See the updated relocation-executable.test for example. llvm-svn: 182908
* ARM: use pristine object file while processing relocationsTim Northover2013-05-281-15/+23
| | | | | | | | | | | | | | Previously we would read-modify-write the target bits when processing relocations for the MCJIT. This had the problem that when relocations were processed multiple times for the same object file (as they can be), the result is not idempotent and the values became corrupted. The solution to this is to take any bits used in the destination from the pristine object file as LLVM emitted it. This should fix PR16013 and remote MCJIT on ARM ELF targets. llvm-svn: 182800
* Add missing header for atexit.Michael J. Spencer2013-05-241-0/+2
| | | | llvm-svn: 182672
* Expose the RTDyldMemoryManager through the C API. This allows clients of Filip Pizlo2013-05-221-3/+111
| | | | | | | | the C API to provide their own way of allocating JIT memory (both code and data) and finalizing memory permissions (page protections, cache flush). llvm-svn: 182448
* Put RTDyldMemoryManager into its own file, and make it linked into Filip Pizlo2013-05-214-96/+117
| | | | | | | | | | | | | | | | | | libExecutionEngine. Move method implementations that aren't specific to allocation out of SectionMemoryManager and into RTDyldMemoryManager. This is in preparation for exposing RTDyldMemoryManager through the C API. This is a fixed version of r182407 and r182411. That first revision broke builds because I forgot to move the conditional includes of various POSIX headers from SectionMemoryManager into RTDyldMemoryManager. Those includes are necessary because of how getPointerToNamedFunction works around the glibc libc_nonshared.a thing. The latter revision still broke things because I forgot to include llvm/Config/config.h. llvm-svn: 182418
* Roll out r182411 and 182412 because it's still broken.Filip Pizlo2013-05-214-116/+96
| | | | llvm-svn: 182415
* Fix busted comment. This conditional include block used to be in ↵Filip Pizlo2013-05-211-1/+1
| | | | | | SectionMemoryManager, but is now in RTDyldMemoryManager. llvm-svn: 182412
* Put RTDyldMemoryManager into its own file, and make it linked into Filip Pizlo2013-05-214-96/+116
| | | | | | | | | | | | | | | | libExecutionEngine. Move method implementations that aren't specific to allocation out of SectionMemoryManager and into RTDyldMemoryManager. This is in preparation for exposing RTDyldMemoryManager through the C API. This is a fixed version of r182407. That revision broke builds because I forgot to move the conditional includes of various POSIX headers from SectionMemoryManager into RTDyldMemoryManager. Those includes are necessary because of how getPointerToNamedFunction works around the glibc libc_nonshared.a thing. llvm-svn: 182411
* Roll out r182407 and r182408 because they broke builds.Filip Pizlo2013-05-215-217/+89
| | | | llvm-svn: 182409
* Expose the RTDyldMemoryManager through the C API. This allows clients of Filip Pizlo2013-05-211-3/+111
| | | | | | | | the C API to provide their own way of allocating JIT memory (both code and data) and finalizing memory permissions (page protections, cache flush). llvm-svn: 182408
* Put RTDyldMemoryManager into its own file, and make it linked into Filip Pizlo2013-05-214-86/+106
| | | | | | | | | | libExecutionEngine. Move method implementations that aren't specific to allocation out of SectionMemoryManager and into RTDyldMemoryManager. This is in preparation for exposing RTDyldMemoryManager through the C API. llvm-svn: 182407
* AArch64: make RuntimeDyld relocations idempotentTim Northover2013-05-191-2/+22
| | | | | | | | | | AArch64 ELF uses .rela relocations so there's no need to actually make use of the bits we're setting in the destination However, we should make sure all bits are cleared properly since multiple runs of resolveRelocations are possible and these could combine to produce invalid results if stale versions remain in the code. llvm-svn: 182214
* r182085 introduced a change that triggered an assertion on ARM. This is an ↵David Tweed2013-05-171-2/+4
| | | | | | | | immediate fix which doesn't resolve the deeper problem. llvm-svn: 182098
* Minor changes to the MCJITTest unittests to use the correct API for finalizingDavid Tweed2013-05-174-3/+10
| | | | | | | the JIT object (including XFAIL an ARM test that now needs fixing). Also renames internal function for consistency. llvm-svn: 182085
* SectionMemoryManager shouldn't be a JITMemoryManager. Previously, the Filip Pizlo2013-05-143-9/+20
| | | | | | | | | | | | | | | | | EngineBuilder interface required a JITMemoryManager even if it was being used to construct an MCJIT. But the MCJIT actually wants a RTDyldMemoryManager. Consequently, the SectionMemoryManager, which is meant for MCJIT, derived from the JITMemoryManager and then stubbed out a bunch of JITMemoryManager methods that weren't relevant to the MCJIT. This patch fixes the situation: it teaches the EngineBuilder that RTDyldMemoryManager is a supertype of JITMemoryManager, and that it's appropriate to pass a RTDyldMemoryManager instead of a JITMemoryManager if we're using the MCJIT. This allows us to remove the stub methods from SectionMemoryManager, and make SectionMemoryManager a direct subtype of RTDyldMemoryManager. llvm-svn: 181820
* Remove dead code.Rafael Espindola2013-05-102-82/+0
| | | | llvm-svn: 181649
* Change getRelocationAdditionalInfo to be ELF only.Rafael Espindola2013-05-091-4/+4
| | | | | | | It was only implemented for ELF where it collected the Addend, so this patch also renames it to getRelocationAddend. llvm-svn: 181502
* Remove exception handling support from the old JIT.Rafael Espindola2013-05-074-669/+1
| | | | llvm-svn: 181354
* PowerPC: Fix unimplemented relocation on ppc64Adhemerval Zanella2013-05-061-0/+5
| | | | | | | This patch handles the R_PPC64_REL64 relocation type for powerpc64 for mcjit. llvm-svn: 181220
* Add EH support to the MCJIT.Rafael Espindola2013-05-058-14/+153
| | | | | | | | | This gets exception handling working on ELF and Macho (x86-64 at least). Other than the EH frame registration, this patch also implements support for GOT relocations which are used to locate the personality function on MachO. llvm-svn: 181167
* AArch64: implement 64-bit absolute relocation in MCJITTim Northover2013-05-041-0/+5
| | | | | | | | | This is about the simplest relocation, but surprisingly rare in actual code. It occurs in (for example) the MCJIT test test-ptr-reloc.ll. llvm-svn: 181134
* AArch64: add stubs to support long function calls on MCJITTim Northover2013-05-043-2/+84
| | | | | | | | | | | | | | | | | | | | As with global accesses, external functions could exist anywhere in memory. Therefore the stub must create a complete 64-bit address. This patch implements the fragment as (roughly): movz x16, #:abs_g3:somefunc movk x16, #:abs_g2_nc:somefunc movk x16, #:abs_g1_nc:somefunc movk x16, #:abs_g0_nc:somefunc br x16 In principle we could save 4 bytes by using a literal-load instead, but it is unclear that would be more efficient and can only be tested when real hardware is readily available. This allows (for example) the MCJIT test 2003-05-07-ArgumentTest to pass on AArch64. llvm-svn: 181133
* AArch64: implement relocations for global accessTim Northover2013-05-041-0/+31
| | | | | | | | | | | | | | | | | The large memory model (default and main viable for JIT) emits addresses in need of relocation as movz x0, #:abs_g3:somewhere movk x0, #:abs_g2_nc:somewhere movk x0, #:abs_g1_nc:somewhere movk x0, #:abs_g0_nc:somewhere To support this we must implement those four relocations in the dynamic loader. This allows (for example) the test-global.ll MCJIT test to pass on AArch64. llvm-svn: 181132
* AArch64: implement first relocation required for MCJITTim Northover2013-05-042-0/+39
| | | | | | | | | | | R_AARCH64_PCREL32 is present in even trivial .eh_frame sections and so is required to compile any function without the "nounwind" attribute. This change implements very basic infrastructure in the RuntimeDyldELF file and allows (for example) the test-shift.ll MCJIT test to pass on AArch64. llvm-svn: 181131
* [SystemZ] Add MCJIT supportRichard Sandiford2013-05-034-0/+113
| | | | | | | | Another step towards reinstating the SystemZ backend. I'll commit the configure changes separately (TARGET_HAS_JIT etc.), then commit a patch to enable the MCJIT tests on SystemZ. llvm-svn: 181015
* This exposes more MCJIT options via the C API:Filip Pizlo2013-05-012-10/+25
| | | | | | | | | | | | | | | | | | | | | CodeModel: It's now possible to create an MCJIT instance with any CodeModel you like. Previously it was only possible to create an MCJIT that used CodeModel::JITDefault. EnableFastISel: It's now possible to turn on the fast instruction selector. The CodeModel option required some trickery. The problem is that previously, we were ensuring future binary compatibility in the MCJITCompilerOptions by mandating that the user bzero's the options struct and passes the sizeof() that he saw; the bindings then bzero the remaining bits. This works great but assumes that the bitwise zero equivalent of any field is a sensible default value. But this is not the case for LLVMCodeModel, or its internal equivalent, llvm::CodeModel::Model. In both of those, the default for a JIT is CodeModel::JITDefault (or LLVMCodeModelJITDefault), which is not bitwise zero. Hence this change introduces LLVMInitializeMCJITCompilerOptions(), which will initialize the user's options struct with defaults. The user will use this in the same way that they would have previously used memset() or bzero(). MCJITCAPITest.cpp illustrates the change, as does the comment in ExecutionEngine.h. llvm-svn: 180893
* This patch breaks up Wrap.h so that it does not have to include all of Filip Pizlo2013-05-011-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | the things, and renames it to CBindingWrapping.h. I also moved CBindingWrapping.h into Support/. This new file just contains the macros for defining different wrap/unwrap methods. The calls to those macros, as well as any custom wrap/unwrap definitions (like for array of Values for example), are put into corresponding C++ headers. Doing this required some #include surgery, since some .cpp files relied on the fact that including Wrap.h implicitly caused the inclusion of a bunch of other things. This also now means that the C++ headers will include their corresponding C API headers; for example Value.h must include llvm-c/Core.h. I think this is harmless, since the C API headers contain just external function declarations and some C types, so I don't believe there should be any nasty dependency issues here. llvm-svn: 180881
* Fix Addend computation for non external relocations on Macho.Rafael Espindola2013-04-301-28/+10
| | | | llvm-svn: 180790
* Collect the Addend for external relocs.Rafael Espindola2013-04-301-5/+12
| | | | | | | This fixes 2013-04-04-RelocAddend.ll. We don't have a testcase for non external relocs with an Addend. I will try to write one. llvm-svn: 180767
* Add getSymbolAlignment to the ObjectFile interface.Rafael Espindola2013-04-294-18/+2
| | | | | | | | | | | | | For regular object files this is only meaningful for common symbols. An object file format with direct support for atoms should be able to provide alignment information for all symbols. This replaces getCommonSymbolAlignment and fixes test-common-symbols-alignment.ll on darwin. This also includes a fix to MachOObjectFile::getSymbolFlags. It was marking undefined symbols as common (already tested by existing mcjit tests now that it is used). llvm-svn: 180736
* Rationalize what is public in RuntimeDyldMachO and RuntimeDyldELF.Rafael Espindola2013-04-292-25/+18
| | | | | | | | The implemented RuntimeDyldImpl interface is public. Everything else is private. Since these classes are not inherited from (yet), there is no need to have protected members. llvm-svn: 180733
OpenPOWER on IntegriCloud