History log of /external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
95a9d937728ca9cf2bf44f86ff1184df318b3bd7 06-Jun-2012 Benjamin Kramer <benny.kra@googlemail.com> Round 2 of dead private variable removal.

LLVM is now -Wunused-private-field clean except for
- lib/MC/MCDisassembler/Disassembler.h. Not sure why it keeps all those unaccessible fields.
- gtest.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158096 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
068c65b22d50c265b51886062b2b9c1cb696d67d 16-May-2012 Danil Malyshev <dmalyshev@accesssoftek.com> Added LLIMCJITMemoryManager to the lli. This manager will be used for MCJIT instead of DefaultJIMMemoryManager.
It's more flexible for MCJIT tasks, in addition it's provides a invalidation instruction cache for code sections which will be used before JIT code will be executed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156933 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
0e4fa5ff365fccff46870b7d5d8d4d1d46e77986 30-Mar-2012 Danil Malyshev <dmalyshev@accesssoftek.com> Re-factored RuntimeDyLd:

1. The main works will made in the RuntimeDyLdImpl with uses the ObjectFile class. RuntimeDyLdMachO and RuntimeDyLdELF now only parses relocations and resolve it. This is allows to make improvements of the RuntimeDyLd more easily. In addition the support for COFF can be easily added.

2. Added ARM relocations to RuntimeDyLdELF.

3. Added support for stub functions for the ARM, allowing to do a long branch.

4. Added support for external functions that are not loaded from the object files, but can be loaded from external libraries. Now MCJIT can correctly execute the code containing the printf, putc, and etc.

5. The sections emitted instead functions, thanks Jim Grosbach. MemoryManager.startFunctionBody() and MemoryManager.endFunctionBody() have been removed.
6. MCJITMemoryManager.allocateDataSection() and MCJITMemoryManager. allocateCodeSection() used JMM->allocateSpace() instead of JMM->allocateCodeSection() and JMM->allocateDataSection(), because I got an error: "Cannot allocate an allocated block!" with object file contains more than one code or data sections.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153754 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
288967dfac246c8e35dc4f85afb667e74d1d26a8 30-Mar-2012 Bill Wendling <isanbard@gmail.com> Revert r153694. It was causing failures in the buildbots.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153701 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
4b0b8ef1b0edc2c343145f6b029c43b00a6f5c13 29-Mar-2012 Danil Malyshev <dmalyshev@accesssoftek.com> Re-factored RuntimeDyld.
Added ExecutionEngine/MCJIT tests.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153694 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
30b9e322e159df8eaabb5b194cec6e11ba99c261 28-Mar-2012 Danil Malyshev <dmalyshev@accesssoftek.com> Move getPointerToNamedFunction() from JIT/MCJIT to JITMemoryManager.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153607 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
3e29671cca14f8fce1ea6b602175880cb3df7199 22-Mar-2012 Chandler Carruth <chandlerc@gmail.com> Revert a series of commits to MCJIT to get the build working in CMake
(and hopefully on Windows). The bots have been down most of the day
because of this, and it's not clear to me what all will be required to
fix it.

The commits started with r153205, then r153207, r153208, and r153221.
The first commit seems to be the real culprit, but I couldn't revert
a smaller number of patches.

When resubmitting, r153207 and r153208 should be folded into r153205,
they were simple build fixes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153241 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
799184d8eb140d02385501223cea0a087148b67b 21-Mar-2012 Danil Malyshev <dmalyshev@accesssoftek.com> Re-factored RuntimeDyld.
Added ExecutionEngine/MCJIT tests.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153221 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
b4746203986e943f3dc0af789c5dc8b34cc85db5 21-Mar-2012 Danil Malyshev <dmalyshev@accesssoftek.com> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153208 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
61425c0a7f4e3608a85f7bbf254cd052a15b7446 16-Jan-2012 Jim Grosbach <grosbach@apple.com> MCJIT support for non-function sections.

Move to a by-section allocation and relocation scheme. This allows
better support for sections which do not contain externally visible
symbols.

Flesh out the relocation address vs. local storage address separation a
bit more as well. Remote process JITs use this to tell the relocation
resolution code where the code will live when it executes.

The startFunctionBody/endFunctionBody interfaces to the JIT and the
memory manager are deprecated. They'll stick around for as long as the
old JIT does, but the MCJIT doesn't use them anymore.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148258 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
2d24e2a396a1d211baaeedf32148a3b657240170 20-Dec-2011 David Blaikie <dblaikie@gmail.com> Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146960 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
afe153c53f525b5599e79f847e2a0723905b6518 12-Nov-2011 Sean Callanan <scallanan@apple.com> Fixed the MCJIT so that it can emit not only instance
methods but also class methods for Objective-C.

Clang emits Objective-C method names with '\1' at the
beginning, and the JIT has pre-existing logic to try
prepending a '\1' when searching a module for an
instance method (that is, a method whose name begins
with '-'). I simply extended it to do the same thing
when it encountered a class method (a method whose
name begins with '+').


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144451 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
3326fc18c859d7988b90345b195d784cc39b3cf6 18-Oct-2011 Jim Grosbach <grosbach@apple.com> The MCJITMemoryManager takes ownership of the JMM, so don't leak it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142410 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
3ec2c7c3e48f1fbab749870c51a74920f91c82c1 19-May-2011 Jim Grosbach <grosbach@apple.com> Objective C functions may use a magic '\1' on the name. Handle that when
dealing with them in the MCJIT.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131601 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
c154514e2daf5497141980544f6b0b03a8e6c37c 12-May-2011 Jim Grosbach <grosbach@apple.com> The MCJIT memory manager needs to initialize its Module member.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131234 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
b027105fa50c864d44873dc78daafb3db3ec9c14 08-Apr-2011 Jim Grosbach <grosbach@apple.com> Refactor MCJIT 32-bit section loading.

Teach 32-bit section loading to use the Memory Manager interface, just like
the 64-bit loading does. Tidy up a few other things here and there.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129138 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
c41ab789a052d7a8a4eacecfa1edd4af0d933990 06-Apr-2011 Jim Grosbach <grosbach@apple.com> RuntimeDyld should use the memory manager API.

Start teaching the runtime Dyld interface to use the memory manager API
for allocating space. Rather than mapping directly into the MachO object,
we extract the payload for each object and copy it into a dedicated buffer
allocated via the memory manager. For now, just do Segment64, so this works
on x86_64, but not yet on ARM.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128973 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
caf767bb027088e28460cde21c721cda681e38fc 06-Apr-2011 Jim Grosbach <grosbach@apple.com> Remove extraneous 'return'.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128959 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h
b572830a52faad2fffc7119de53aa96c18d9bf07 05-Apr-2011 Jim Grosbach <grosbach@apple.com> Add missing file from r128851.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128856 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/ExecutionEngine/MCJIT/MCJITMemoryManager.h