| Age | Commit message (Collapse) | Author |
|---|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172627 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172515 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Do proper casting to eliminate a const-away-cast compiler warning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172470 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Properly cast some more code that triggered cast-away-const errors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172469 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Michael Muller.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172214 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171979 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to create a properly aligned reader.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171520 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171506 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171259 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
mangling prefix to this symbol.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171025 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170902 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170350 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
For OS X builds, we generate one version of config.h but then build for
multiple architectures. This means that the LLVM_HOSTTRIPLE setting may have
the wrong architecture. Adjust it dynamically to match the current
architecture. <rdar://problem/12715470>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169405 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
missed in the first pass because the script didn't yet handle include
guards.
Note that the script is now able to handle all of these headers without
manual edits. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169224 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169183 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This small change adds support for that. It will make all MCJIT tests pass
in make-check on BigEndian platforms.
Patch by Petar Jovanovic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169178 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
depends on the IR infrastructure, there is no sense in it being off in
Support land.
This is in preparation to start working to expand InstVisitor into more
special-purpose visitors that are still generic and can be re-used
across different passes. The expansion will go into the Analylis tree
though as nothing in VMCore needs it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168972 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Unbreaks the CMake shared library build. This is nasty and should be fixed
eventually.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168800 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and RuntimeDyld
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168755 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The SectionMemoryManager now supports (and requires) applying section-specific page permissions. Clients using this memory manager must call either MCJIT::finalizeObject() or SectionMemoryManager::applyPermissions() before executing JITed code.
See r168718 for changes from the previous implementation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168721 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
FinalizeProcessFunc, for now. [-Wunused-private-field]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168495 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Tests to follow in another patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168444 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
all symbols during object loading, not just global ones.
This fixes JIT execution of code using llvm.global_ctors with internal
linkage constructors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168148 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
permissions after an object has been loaded.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168114 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167968 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167477 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch adds the interface to expose events from MCJIT when an object is emitted or freed and implements the MCJIT functionality to send those events. The IntelJITEventListener implementation is left empty for now. It will be fleshed out in a future patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167475 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Prior to this patch RuntimeDyld attempted to re-apply relocations every time reassignSectionAddress was called (via MCJIT::mapSectionAddress). In addition to being inefficient and redundant, this led to a problem when a section was temporarily moved too far away from another section with a relative relocation referencing the section being moved. To fix this, I'm adding a new method (finalizeObject) which the client can call to indicate that it is finished rearranging section addresses so the relocations can safely be applied.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167400 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
values in the original object buffer.
Some ELF relocations require adding the a value to the original contents of the object buffer at the specified location. In order to properly handle multiple applications of a relocation, the RuntimeDyld code should be grabbing the original value from the object buffer and writing a new value into the loaded section buffer. This patch changes the parameters passed to resolveRelocations to accommodate this need.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167304 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167247 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
r165941: Resubmit the changes to llvm core to update the functions to
support different pointer sizes on a per address space basis.
Despite this commit log, this change primarily changed stuff outside of
VMCore, and those changes do not carry any tests for correctness (or
even plausibility), and we have consistently found questionable or flat
out incorrect cases in these changes. Most of them are probably correct,
but we need to devise a system that makes it more clear when we have
handled the address space concerns correctly, and ideally each pass that
gets updated would receive an accompanying test case that exercises that
pass specificaly w.r.t. alternate address spaces.
However, from this commit, I have retained the new C API entry points.
Those were an orthogonal change that probably should have been split
apart, but they seem entirely good.
In several places the changes were very obvious cleanups with no actual
multiple address space code added; these I have not reverted when
I spotted them.
In a few other places there were merge conflicts due to a cleaner
solution being implemented later, often not using address spaces at all.
In those cases, I've preserved the new code which isn't address space
dependent.
This is part of my ongoing effort to clean out the partial address space
code which carries high risk and low test coverage, and not likely to be
finished before the 3.2 release looms closer. Duncan and I would both
like to see the above issues addressed before we return to these
changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167222 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Ashok Thirumurthi
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167192 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167057 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Amara Emerson.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166919 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch adds initial support for MCJIT for PPC64-elf-abi. The TOC
relocation and ODP handling is implemented.
It fixes the following ExecutionEngine testcases:
ExecutionEngine/2003-01-04-ArgumentBug.ll
ExecutionEngine/2003-01-04-LoopTest.ll
ExecutionEngine/2003-01-04-PhiTest.ll
ExecutionEngine/2003-01-09-SARTest.ll
ExecutionEngine/2003-01-10-FUCOM.ll
ExecutionEngine/2003-01-15-AlignmentTest.ll
ExecutionEngine/2003-05-11-PHIRegAllocBug.ll
ExecutionEngine/2003-06-04-bzip2-bug.ll
ExecutionEngine/2003-06-05-PHIBug.ll
ExecutionEngine/2003-08-15-AllocaAssertion.ll
ExecutionEngine/2003-08-21-EnvironmentTest.ll
ExecutionEngine/2003-08-23-RegisterAllocatePhysReg.ll
ExecutionEngine/2003-10-18-PHINode-ConstantExpr-CondCode-Failure.ll
ExecutionEngine/simplesttest.ll
ExecutionEngine/simpletest.ll
ExecutionEngine/stubs.ll
ExecutionEngine/test-arith.ll
ExecutionEngine/test-branch.ll
ExecutionEngine/test-call-no-external-funcs.ll
ExecutionEngine/test-cast.ll
ExecutionEngine/test-common-symbols.ll
ExecutionEngine/test-constantexpr.ll
ExecutionEngine/test-fp-no-external-funcs.ll
ExecutionEngine/test-fp.ll
ExecutionEngine/test-global-init-nonzero.ll
ExecutionEngine/test-global.ll
ExecutionEngine/test-loadstore.ll
ExecutionEngine/test-local.ll
ExecutionEngine/test-logical.ll
ExecutionEngine/test-loop.ll
ExecutionEngine/test-phi.ll
ExecutionEngine/test-ret.ll
ExecutionEngine/test-return.ll
ExecutionEngine/test-setcond-fp.ll
ExecutionEngine/test-setcond-int.ll
ExecutionEngine/test-shift.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166678 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166607 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166485 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
different pointer sizes on a per address space basis.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165941 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
while processing relocations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165854 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165785 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
isa<> et al. automatically infer when the cast is an upcast (including a
self-cast), so these are no longer necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165767 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This classof() is effectively saying that a MachineCodeEmitter "is-a"
JITEmitter, but JITEmitter is in fact a descendant of
MachineCodeEmitter, so this is not semantically correct. Consequently,
none of the assertions that rely on these classof() actualy check
anything.
Remove the RTTI (which didn't actually check anything) and use
static_cast<> instead.
Post-Mortem Bug Analysis
========================
Cause of the bug
----------------
r55022 appears to be the source of the classof() and assertions removed
by this commit. It aimed at removing some dynamic_cast<> that were
solely in the assertions. A typical diff hunk from that commit looked
like:
- assert(dynamic_cast<JITEmitter*>(MCE) && "Unexpected MCE?");
- JITEmitter *JE = static_cast<JITEmitter*>(getCodeEmitter());
+ assert(isa<JITEmitter>(MCE) && "Unexpected MCE?");
+ JITEmitter *JE = cast<JITEmitter>(getCodeEmitter());
Hence, the source of the bug then seems to be an attempt to replace
dynamic_cast<> with LLVM-style RTTI without properly setting up the
class hierarchy for LLVM-style RTTI. The bug therefore appears to be
simply a "thinko".
What initially indicated the presence of the bug
------------------------------------------------
After implementing automatic upcasting for isa<>, classof() functions of
the form
static bool classof(const Foo *) { return true; }
were removed, since they only serve the purpose of optimizing
statically-OK upcasts. A subsequent recompilation triggered a build
failure on the isa<> tests within the removed asserts, since the
automatic upcasting (correctly) failed to substitute this classof().
Key to pinning down the root cause of the bug
---------------------------------------------
After being alerted to the presence of the bug, some thought about the
semantics which were being asserted by the buggy classof() revealed that
it was incorrect.
How the bug could have been prevented
-------------------------------------
This bug could have been prevented by better documentation for how to
set up LLVM-style RTTI. This should be solved by the recently added
documentation HowToSetUpLLVMStyleRTTI. However, this bug suggests that
the documentation should clearly explain the contract that classof()
must fulfill. The HowToSetUpLLVMStyleRTTI already explains this
contract, but it is a little tucked away. A future patch will expand
that explanation and make it more prominent.
There does not appear to be a simple way to have the compiler prevent
this bug, since fundamentally it boiled down to a spurious classof()
where the programmer made an erroneous statement about the conversion.
This suggests that perhaps the interface to LLVM-style RTTI of classof()
is not the best. There is already some evidence for this, since in a
number of places Clang has classof() forward to classofKind(Kind K)
which evaluates the cast in terms of just the Kind. This could probably
be generalized to simply a `static const Kind MyKind;` field in leaf
classes and `static const Kind firstMyKind, lastMyKind;` for non-leaf
classes, and have the rest of the work be done inside Casting.h,
assuming that the Kind enum is laid out in a preorder traversal of the
inheritance tree.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165764 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165747 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
per address space pointer sizes to be optimized correctly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165726 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch committed on behalf of Kirill Uhanov
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165589 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165402 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Amara Emerson.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165128 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165053 91177308-0d34-0410-b5e6-96231b3b80d8
|
