The new ORC remote-JITing support provides a superset of the old code's
functionality, so we can replace the old stuff. As a bonus, a couple of
previously XFAILed tests have started passing.
llvm-svn: 257343
This inlines materializeAll into the only caller
(materializeAllPermanently) and renames materializeAllPermanently to
just materializeAll.
llvm-svn: 256024
to use the information in the module rather than TargetOptions.
We've had and clang has used the use-soft-float attribute for some
time now so have the backends set a subtarget feature based on
a particular function now that subtargets are created based on
functions and function attributes.
For the one middle end soft float check go ahead and create
an overloadable TargetLowering::useSoftFloat function that
just checks the TargetSubtargetInfo in all cases.
Also remove the command line option that hard codes whether or
not soft-float is set by using the attribute for all of the
target specific test cases - for the generic just go ahead and
add the attribute in the one case that showed up.
llvm-svn: 237079
The patch is generated using clang-tidy misc-use-override check.
This command was used:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
-checks='-*,misc-use-override' -header-filter='llvm|clang' \
-j=32 -fix -format
http://reviews.llvm.org/D8925
llvm-svn: 234679
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
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
llvm-svn: 226940
Summary:
The default copy and assignment operators for these objects probably don't actually do what the clients intend, so they should be deleted.
Places using the assignment operator to set the value of an option should cast to the option's data type first to call into the override for operator=. Places using the copy constructor just need to be changed to not copy (i.e. passing by const reference instead of value).
Reviewers: dexonsmith, chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7114
llvm-svn: 226762
This patch removes the old JIT memory manager (which does not provide any
useful functionality now that the old JIT is gone), and migrates the few
remaining clients over to SectionMemoryManager.
http://llvm.org/PR20848
llvm-svn: 218316
Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even better, but this patch is already a bit too
big.
llvm-svn: 216393
Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.
Keeping this ownership would make supporting IR inside native objects
particularly painful.
This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.
This patch introduces a few new types.
* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
for convenience functions that take a filename and return both the
buffer and the Binary using that buffer.
The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.
llvm-svn: 216002
be deleted. This will be reapplied as soon as possible and before
the 3.6 branch date at any rate.
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reverts commits r215111, 215115, 215116, 215117, 215136.
llvm-svn: 215154
I am sure we will be finding bits and pieces of dead code for years to
come, but this is a good start.
Thanks to Lang Hames for making MCJIT a good replacement!
llvm-svn: 215111
This starts in MCJIT::getSymbolAddress where the
unique_ptr<object::Binary> is release()d and (after a cast) passed to a
single caller, MCJIT::addObjectFile.
addObjectFile calls RuntimeDyld::loadObject.
RuntimeDld::loadObject calls RuntimeDyldELF::createObjectFromFile
And the pointer is never owned at this point. I say this point, because
the alternative codepath, RuntimeDyldMachO::createObjectFile certainly
does take ownership, so this seemed like a good hint that this was a/the
right place to take ownership.
llvm-svn: 207580
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
llvm-svn: 203083
After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)
llvm-svn: 202052
Eliminates the LLI_BUILDING_CHILD build hack from r199885.
Also add a FIXME to remove code that tricks the tests into passing when the
feature fails to work. Please don't do stuff like this, the tests exist for a
reason!
llvm-svn: 199929
MCJIT remote execution (ChildTarget+RemoteTargetExternal) protocol was in
dire need of refactoring. It was fail-prone, had no error reporting and
implemented the same message logic on every single function.
This patch rectifies it, and makes it work on ARM, where it was randomly
failing. Other architectures shall profit from this change as well, making
their buildbots and releases more reliable.
llvm-svn: 199261
root path to which object files managed by the LLIObjectCache instance should be
written. This option defaults to "", in which case objects are cached in the
same directory as the bitcode they are derived from.
The load-object-a.ll test has been rewritten to use this option to support
testing in environments where the test directory is not writable.
llvm-svn: 198852
I believe the bot failures on linux systems were due to overestimating the
alignment of object-files within archives, which are only guaranteed to be
two-byte aligned. I have reduced the alignment in
RuntimeDyldELF::createObjectImageFromFile accordingly.
llvm-svn: 198737
This fixes a problem from a previous check-in where a return value was omitted.
Previously the remote/stubs-remote.ll and remote/stubs-sm-pic.ll tests were reporting passes, but they should have been failing. Those tests attempt to link against an external symbol and remote symbol resolution is not supported. The old RemoteMemoryManager implementation resulted in local symbols being used for resolution and the child process crashed but the test didn't notice. With this check-in remote symbol resolution fails, and so the test (correctly) fails.
llvm-svn: 192514
At this time only Unix-based systems are supported. Windows has stubs and should re-route to the simulated mode.
Thanks to Sriram Murali for contributions to this patch.
llvm-svn: 191843
Tests to follow.
PIC with small code model and EH frame handling will not work with multiple modules. There are also some rough edges to be smoothed out for remote target support.
llvm-svn: 191722
- warn users when -debug-ir is used with old JIT engine (only partial debug
info is available)
For example, to debug an IR file with GDB (that supports JIT registration), do:
$ gdb --args lli -use-mcjit -debug-ir testcase.ll
(gdb) break main
(gdb) run
<Process continues to lli main>
(gdb) continue
<Process continues to testcase.ll main()
(gdb) step
<Now stepping through the LLVM IR in testcase.ll>
llvm-svn: 185197
On 32-bit hosts %p can print garbage when given a uint64_t, we should
use %llx instead. This only affects the output of the debugging text
produced by lli.
llvm-svn: 182209
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
its own library. These functions are bridging between the bitcode reader
and the ll parser which are in different libraries. Previously we didn't
have any good library to do this, and instead played fast and loose with
a "header only" set of interfaces in the Support library. This really
doesn't work well as evidenced by the recent attempt to add timing logic
to the these routines.
As part of this, make them normal functions rather than weird inline
functions, and sink the implementation into the library. Also clean up
the header to be nice and minimal.
This requires updating lots of build system dependencies to specify that
the IRReader library is needed, and several source files to not
implicitly rely upon the header file to transitively include all manner
of other headers.
If you are using IRReader.h, this commit will break you (the header
moved) and you'll need to also update your library usage to include
'irreader'. I will commit the corresponding change to Clang momentarily.
llvm-svn: 177971
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
Again, tools are trickier to pick the main module header for than
library source files. I've started to follow the pattern of using
LLVMContext.h when it is included as a stub for program source files.
llvm-svn: 169252
The functionality of SectionMemoryManager is equivalent to the LLIMCJITMemoryManager being replaced except that it allocates memory as RW and later changes it to RX or R as needed. The page permissions are set in the call to MCJIT::finalizeObject.
llvm-svn: 168722
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.
llvm-svn: 167400
Simulate a remote target address space by allocating a seperate chunk of
memory for the target and re-mapping section addresses to that prior to
execution. Later we'll want to have a truly remote process, but for now
this gets us closer to being able to test the remote target
functionality outside LLDB.
rdar://12157052
llvm-svn: 163216
Invalidate the instruction cache right before we start actually executing code, otherwise
we can miss some that came later. This is still not quite right for a truly lazilly
compiled environment, but it's closer.
llvm-svn: 162803
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.
llvm-svn: 156933
Also refactor the existing OProfile profiling code to reuse the same interfaces with the VTune profiling code.
In addition, unit tests for the profiling interfaces were added.
This patch was prepared by Andrew Kaylor and Daniel Malea, and reviewed in the llvm-commits list by Jim Grosbach
llvm-svn: 152620
the X86 asmparser to produce ranges in the one case that was annoying me, for example:
test.s:10:15: error: invalid operand for instruction
movl 0(%rax), 0(%edx)
^~~~~~~
It should be straight-forward to enhance filecheck, tblgen, and/or the .ll parser to use
ranges where appropriate if someone is interested.
llvm-svn: 142106
- Introduce JITDefault code model. This tells targets to set different default
code model for JIT. This eliminates the ugly hack in TargetMachine where
code model is changed after construction.
llvm-svn: 135580
(including compilation, assembly). Move relocation model Reloc::Model from
TargetMachine to MCCodeGenInfo so it's accessible even without TargetMachine.
llvm-svn: 135468
Proof-of-concept code that code-gens a module to an in-memory MachO object.
This will be hooked up to a run-time dynamic linker library (see: llvm-rtdyld
for similarly conceptual work for that part) which will take the compiled
object and link it together with the rest of the system, providing back to the
JIT a table of available symbols which will be used to respond to the
getPointerTo*() queries.
llvm-svn: 127916
llc.cpp also defined these flags, meaning that when I linked all of LLVM's
libraries into a single shared library, llc crashed on startup with duplicate
flag definitions. This patch passes them through the EngineBuilder into
JIT::selectTarget().
llvm-svn: 95390
Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules, it's renamed to
"GVMaterializer". Code that used to need a ModuleProvider to materialize
Functions can now materialize the Functions directly. Functions no longer use a
magic linkage to record that they're materializable; they simply ask the
GVMaterializer.
Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
the functions that refer to it. Instead, because Module now exposes the same
functionality ModuleProvider used to, we store a Module* in any
LLVMModuleProviderRef and translate in the wrapper methods. The bindings to
other languages still use the ModuleProvider concept. It would probably be
worth some time to update them to follow the C++ more closely, but I don't
intend to do it.
Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.
llvm-svn: 94686
http://llvm.org/PR5184, and beef up the comments to describe what both options
do and the risks of lazy compilation in the presence of threads.
llvm-svn: 85295
forcing them down into various .cpp files.
This change also:
1. Renames TimeValue::toString() and Path::toString() to ::str()
for similarity with the STL.
2. Removes all stream insertion support for sys::Path, forcing
clients to call .str().
3. Removes a use of Config/alloca.h from bugpoint, using smallvector
instead.
4. Weans llvm-db off <iostream>
sys::Path really needs to be gutted, but I don't have the desire to
do it at this point.
llvm-svn: 79869
out of memory, and also make the default memory manager allocate more memory
when it runs out.
Also, switch function stubs and global data over to using the BumpPtrAllocator.
This makes it so the JIT no longer mmaps (or the equivalent on Windows) 16 MB
of memory, and instead allocates in 512K slabs. I suspect this size could go
lower, especially on embedded platforms, now that more slabs can be allocated.
llvm-svn: 76828
- Otherwise we get two regressions in llvm-test for applications which run out
of space.
- Once the JIT memory manager is improved, this can be switched back.
llvm-svn: 76291
library to tell it the addresses of JITted functions. For a
particular program, this changes the opreport -l output from:
samples % image name symbol name
48182 98.9729 anon (tgid:19412 range:0x7f12ccaab000-0x7f12cdaab000) anon (tgid:19412 range:0x7f12ccaab000-0x7f12cdaab000)
11 0.0226 libstdc++.so.6.0.9 /usr/lib/libstdc++.so.6.0.9
to:
samples % image name symbol name
24565 60.7308 19814.jo fib_left
15365 37.9861 19814.jo fib_right
22 0.0544 ld-2.7.so do_lookup_x
llvm-svn: 75279
emitted or the machine code for a function is freed. Chris mentioned that we
may also want a notification when a stub is emitted, but that'll be a future
change. I intend to use this to tell oprofile where functions are emitted and
what lines correspond to what addresses.
llvm-svn: 74157
NAKAMURA Takumi