| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 180790
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 180725
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 180723
|
|
|
|
|
|
|
|
| |
Re-submitting with fix for OCaml dependency problems (removing dependency on SectionMemoryManager when it isn't used).
Patch by Fili Pizlo
llvm-svn: 180720
|
|
|
|
|
|
| |
This gets most of the MCJITs tests passing with MachO.
llvm-svn: 180716
|
|
|
|
|
|
|
|
|
|
|
| |
For MachO we need information that is not represented in ObjRelocationInfo.
Instead of copying the bits we think are needed from a relocation_iterator,
just pass the relocation_iterator down to the format specific functions.
No functionality change yet as we still drop the information once
processRelocationRef returns.
llvm-svn: 180711
|
|
|
|
|
|
|
|
| |
arithmetic operations.
Patch by Yuri Veselov.
llvm-svn: 180626
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For Mach-O there were 2 implementations for parsing object files. A
standalone llvm/Object/MachOObject.h and llvm/Object/MachO.h which
implements the generic interface in llvm/Object/ObjectFile.h.
This patch adds the missing features to MachO.h, moves macho-dump to
use MachO.h and removes ObjectFile.h.
In addition to making sure that check-all is clean, I checked that the
new version produces exactly the same output in all Mach-O files in a
llvm+clang build directory (including executables and shared
libraries).
To test the performance, I ran macho-dump over all the files in a
llvm+clang build directory again, but this time redirecting the output
to /dev/null. Both the old and new versions take about 4.6 seconds
(2.5 user) to finish.
llvm-svn: 180624
|
|
|
|
| |
llvm-svn: 180575
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 07f03923137a91e3cca5d7fc075a22f8c9baf33a.
Looks like it broke the valgrind bot:
http://lab.llvm.org:8011/builders/llvm-x86_64-linux-vg_leak/builds/649
llvm-svn: 180249
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 8c31b298149ca3c3f2bbd9e8aa9a01c4d91f3d74.
It looks like this commit broke some bots:
http://lab.llvm.org:8011/builders/llvm-ppc64-linux2/builds/5209
llvm-svn: 180248
|
|
|
|
|
|
| |
Patch by Filip Pizlo
llvm-svn: 180229
|
|
|
|
| |
llvm-svn: 180225
|
|
|
|
|
|
| |
Patch by Tom Stellard. (Committed while he's afk per request)
llvm-svn: 180157
|
|
|
|
| |
llvm-svn: 180146
|
|
|
|
| |
llvm-svn: 180112
|
|
|
|
|
|
|
| |
or the C++ files themselves. This enables people to use
just a C compiler to interoperate with LLVM.
llvm-svn: 180063
|
|
|
|
|
|
|
|
|
|
| |
* We only ever specialize these templates with an instantiation of ELFType,
so we don't need a template template.
* Replace LLVM_ELF_COMMA with just passing the individual parameters to the
macro. This requires a second macro for when we only have ELFT, but that
is still a small win.
llvm-svn: 179726
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I will remove the isBigEndianHost function once I update clang.
The ifdef logic is designed to
* not use configure/cmake to avoid breaking -arch i686 -arch ppc.
* default to little endian
* be as small as possible
It looks like sys/endian.h is the preferred header on most modern BSD systems,
but it is better to change this in a followup patch as machine/endian.h is
available on FreeBSD, OpenBSD, NetBSD and OS X.
llvm-svn: 179527
|
|
|
|
| |
llvm-svn: 179418
|
|
|
|
|
|
| |
patch by Veselov, Yuri <Yuri.Veselov@intel.com>.
llvm-svn: 179409
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the RuntimeDyldELF::processRelocationRef routine finds the target
symbol of a relocation in the local or global symbol table, it performs
a section-relative relocation:
Value.SectionID = lsi->second.first;
Value.Addend = lsi->second.second;
At this point, however, any Addend that might have been specified in
the original relocation record is lost. This is somewhat difficult to
trigger for relocations within the code section since they usually
do not contain non-zero Addends (when built with the default JIT code
model, in any case). However, the problem can be reliably triggered
by a relocation within the data section caused by code like:
int test[2] = { -1, 0 };
int *p = &test[1];
The initializer of "p" will need a relocation to "test + 4". On
platforms using RelA relocations this means an Addend of 4 is required.
Current code ignores this addend when processing the relocation,
resulting in incorrect execution.
Fixed by taking the Addend into account when processing relocations
to symbols found in the local or global symbol table.
Tested on x86_64-linux and powerpc64-linux.
llvm-svn: 178869
|
|
|
|
|
|
|
| |
Patch by:
Veselov, Yuri <Yuri.Veselov@intel.com>
llvm-svn: 178469
|
|
|
|
| |
llvm-svn: 175647
|
|
|
|
|
|
| |
relocation is given with no name and an undefined section. The relocation is applied with an address of zero.
llvm-svn: 175643
|
|
|
|
|
|
|
|
| |
Add #include <unistd.h> to OProfileWrapper.cpp. This provides the declarations for 'read' and 'close' that are otherwise missing, and result in 'error: <foo> was not declared in this scope'.
This matches the issue as reported in bug 15055 "Can no longer compile LLVM with --with-oprofile"
llvm-svn: 174661
|
|
|
|
| |
llvm-svn: 174205
|
|
|
|
| |
llvm-svn: 174080
|
|
|
|
| |
llvm-svn: 174078
|
|
|
|
| |
llvm-svn: 173739
|
|
|
|
|
|
| |
object emitted by MCJIT.
llvm-svn: 173712
|
|
|
|
|
|
| |
and, in the case of ELF files, using symbol addresses when available for relocations to the .debug_info section. Also extending the llvm-rtdyld tool to add the ability to dump line number information for testing purposes.
llvm-svn: 173517
|
|
|
|
|
|
|
|
|
| |
Previously we tried to infer it from the bit width size, with an added
IsIEEE argument for the PPC/IEEE 128-bit case, which had a default
value. This default value allowed bugs to creep in, where it was
inappropriate.
llvm-svn: 173138
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r143502, we renamed getHostTriple() to getDefaultTargetTriple()
as part of work to allow the user to supply a different default
target triple at configure time. This change also affected the JIT.
However, it is inappropriate to use the default target triple in the
JIT in most circumstances because this will not necessarily match
the current architecture used by the process, leading to illegal
instruction and other such errors at run time.
Introduce the getProcessTriple() function for use in the JIT and
its clients, and cause the JIT to use it. On architectures with a
single bitness, the host and process triples are identical. On other
architectures, the host triple represents the architecture of the
host CPU, while the process triple represents the architecture used
by the host CPU to interpret machine code within the current process.
For example, when executing 32-bit code on a 64-bit Linux machine,
the host triple may be 'x86_64-unknown-linux-gnu', while the process
triple may be 'i386-unknown-linux-gnu'.
This fixes JIT for the 32-on-64-bit (and vice versa) build on non-Apple
platforms.
Differential Revision: http://llvm-reviews.chandlerc.com/D254
llvm-svn: 172627
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies the usage and implementation of ELFObjectFile by using ELFType
to replace:
<endianness target_endianness, std::size_t max_alignment, bool is64Bits>
This does complicate the base ELF types as they must now use template template
parameters to partially specialize for the 32 and 64bit cases. However these
are only defined once.
llvm-svn: 172515
|
|
|
|
|
|
| |
Do proper casting to eliminate a const-away-cast compiler warning.
llvm-svn: 172470
|
|
|
|
|
|
| |
Properly cast some more code that triggered cast-away-const errors.
llvm-svn: 172469
|
|
|
|
|
|
| |
Patch by Michael Muller.
llvm-svn: 172214
|
|
|
|
|
|
|
|
|
| |
This patch adjust the r171506 to make all DWARF enconding pc-relative
for PPC64. It also adds the R_PPC64_REL32 relocation handling in MCJIT
(since the eh_frame will not generate PIC-relative relocation) and also
adds the emission of stubs created by the TTypeEncoding.
llvm-svn: 171979
|
|
|
|
|
|
| |
to create a properly aligned reader.
llvm-svn: 171520
|
|
|
|
|
|
|
|
|
| |
This patch fixes the PPC eh_frame definitions for the personality and
frame unwinding for PIC objects. It makes PIC build correctly creates
relative relocations in the '.rela.eh_frame' segments and thus avoiding
a text relocation that generates a DT_TEXTREL segments in link phase.
llvm-svn: 171506
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
llvm-svn: 171366
|
|
|
|
|
|
|
|
|
| |
GEP::accumulateConstantOffset().
The later API is nicer than the former, and is correct regarding wrap-around offsets (if anyone cares).
There are a few more places left with duplicated code, which I'll remove soon.
llvm-svn: 171259
|
|
|
|
|
|
| |
mangling prefix to this symbol.
llvm-svn: 171025
|
|
|
|
| |
llvm-svn: 170902
|