The OptLevel is now redundant with the TargetMachine*.
And selectTarget() isn't really JIT-specific and could probably
get refactored into one of the lower level libraries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146355 91177308-0d34-0410-b5e6-96231b3b80d8
generator to it. For non-bundle instructions, these behave exactly the same
as the MC layer API.
For properties like mayLoad / mayStore, look into the bundle and if any of the
bundled instructions has the property it would return true.
For properties like isPredicable, only return true if *all* of the bundled
instructions have the property.
For properties like canFoldAsLoad, isCompare, conservatively return false for
bundles.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146026 91177308-0d34-0410-b5e6-96231b3b80d8
change, now you need a TargetOptions object to create a TargetMachine. Clang
patch to follow.
One small functionality change in PTX. PTX had commented out the machine
verifier parts in their copy of printAndVerify. That now calls the version in
LLVMTargetMachine. Users of PTX who need verification disabled should rely on
not passing the command-line flag to enable it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145714 91177308-0d34-0410-b5e6-96231b3b80d8
It was getting ignored after r144788.
Also fix an accidental implicit cast from the OptLevel enum
to an optional bool argument. MSVC warned on this, but gcc
didn't.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145633 91177308-0d34-0410-b5e6-96231b3b80d8
and code model. This eliminates the need to pass OptLevel flag all over the
place and makes it possible for any codegen pass to use this information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144788 91177308-0d34-0410-b5e6-96231b3b80d8
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
specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.
I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.
This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.
This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.
Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.
This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136433 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135580 91177308-0d34-0410-b5e6-96231b3b80d8
(including compilation, assembly). Move relocation model Reloc::Model from
TargetMachine to MCCodeGenInfo so it's accessible even without TargetMachine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135468 91177308-0d34-0410-b5e6-96231b3b80d8
errors like the one corrected by r135261. Migrate all LLVM callers of the old
constructor to the new one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135431 91177308-0d34-0410-b5e6-96231b3b80d8
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
be the first encoded as the first feature. It then uses the CPU name to look up
features / scheduling itineray even though clients know full well the CPU name
being used to query these properties.
The fix is to just have the clients explictly pass the CPU name!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134127 91177308-0d34-0410-b5e6-96231b3b80d8
As an ExecutionEngine class function, its definition
really belongs in ExecutionEngine.cpp, not JIT.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131320 91177308-0d34-0410-b5e6-96231b3b80d8
In particular, into EngineBuilder. This should only impact
the private API between the EE and EB classes, not external
clients, since JITCtor and MCJITCtor are both protected members.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131317 91177308-0d34-0410-b5e6-96231b3b80d8
This prepares for making JITCtor/MCJITCtor take a
TargetMachine* directly from clients like EngineBuilder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131316 91177308-0d34-0410-b5e6-96231b3b80d8
actually takes rather than how much memory was allocated for it. This
is more accurate and should help the manager pack things more effectively.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131305 91177308-0d34-0410-b5e6-96231b3b80d8
erroring out completely. Some modules produce sections that aren't referenced,
so it's friendlier to clients like LLDB to just skip them, at least for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131243 91177308-0d34-0410-b5e6-96231b3b80d8
As an ExecutionEngine class function, its definition
really belongs in ExecutionEngine.cpp, not JIT.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131027 91177308-0d34-0410-b5e6-96231b3b80d8
In particular, into EngineBuilder. This should only impact
the private API between the EE and EB classes, not external
clients, since JITCtor and MCJITCtor are both protected members.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131026 91177308-0d34-0410-b5e6-96231b3b80d8
This prepares for making JITCtor/MCJITCtor take a
TargetMachine* directly from clients like EngineBuilder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131025 91177308-0d34-0410-b5e6-96231b3b80d8
a bit more sinister as the memset doesn't do what the constructor does.
There seems to be a cleaner solution than a cast here though, instead we
can point the memset destination into the union its actually trying to
clear.
An alternative is to point to the Untyped member of this union. Review
appreciated, and if that is cleaner I'm happy to switch. All of these
should be functionally equivalent to the original code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130395 91177308-0d34-0410-b5e6-96231b3b80d8
Add handling for tracking the relocations on symbols and resolving them.
Keep track of the relocations even after they are resolved so that if
the RuntimeDyld client moves the object, it can update the address and any
relocations to that object will be updated.
For our trival object file load/run test harness (llvm-rtdyld), this enables
relocations between functions located in the same object module. It should
be trivially extendable to load multiple objects with mutual references.
As a simple example, the following now works (running on x86_64 Darwin 10.6):
$ cat t.c
int bar() {
return 65;
}
int main() {
return bar();
}
$ clang t.c -fno-asynchronous-unwind-tables -o t.o -c
$ otool -vt t.o
t.o:
(__TEXT,__text) section
_bar:
0000000000000000 pushq %rbp
0000000000000001 movq %rsp,%rbp
0000000000000004 movl $0x00000041,%eax
0000000000000009 popq %rbp
000000000000000a ret
000000000000000b nopl 0x00(%rax,%rax)
_main:
0000000000000010 pushq %rbp
0000000000000011 movq %rsp,%rbp
0000000000000014 subq $0x10,%rsp
0000000000000018 movl $0x00000000,0xfc(%rbp)
000000000000001f callq 0x00000024
0000000000000024 addq $0x10,%rsp
0000000000000028 popq %rbp
0000000000000029 ret
$ llvm-rtdyld t.o -debug-only=dyld ; echo $?
Function sym: '_bar' @ 0
Function sym: '_main' @ 16
Extracting function: _bar from [0, 15]
allocated to 0x100153000
Extracting function: _main from [16, 41]
allocated to 0x100154000
Relocation at '_main' + 16 from '_bar(Word1: 0x2d000000)
Resolving relocation at '_main' + 16 (0x100154010) from '_bar (0x100153000)(pcrel, type: 2, Size: 4).
loaded '_main' at: 0x100154000
65
$
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129388 91177308-0d34-0410-b5e6-96231b3b80d8
mean that it has to be ConstantArray of ConstantStruct. We might have
ConstantAggregateZero, at either level, so don't crash on that.
Also, semi-deprecate the sentinal value. The linker isn't aware of sentinals so
we end up with the two lists appended, each with their "sentinals" on them.
Different parts of LLVM treated sentinals differently, so make them all just
ignore the single entry and continue on with the rest of the list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129307 91177308-0d34-0410-b5e6-96231b3b80d8
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
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
The JITMemory manager references LLVM IR constructs directly, while the
runtime Dyld works at a lower level and can handle objects which may not
originate from LLVM IR. Introduce a new layer for the memory manager to
handle the interface between them. For the MCJIT, this layer will be almost
entirely simply a call-through w/ translation between the IR objects and
symbol names.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128851 91177308-0d34-0410-b5e6-96231b3b80d8
The ExecutionEngine constructor already added the module, so there's no
need to call addModule() directly. Doing so causes a double-free of the
Module at program termination.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128171 91177308-0d34-0410-b5e6-96231b3b80d8
Support argument passing simple, common, prototypes directly. More
complicated scenarios will require building up a stub function, which the
MC-JIT isn't set up to handle yet.
Add Intercept.cpp, which is just a copy from ExecutionEngine/JIT for now,
to handle looking looking up external symbol names. This probably more
properly belongs as part of RuntimeDyld. It'll migrate there as things
flesh out more fully.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128090 91177308-0d34-0410-b5e6-96231b3b80d8
Lots of cleanup to make the interfaces prettier, use the JITMemoryManager,
handle multiple functions and modules, etc.. This gets far enough that
the MCJIT compiles and runs code, though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128052 91177308-0d34-0410-b5e6-96231b3b80d8
Move the dynamic linking functionality of the llvm-rtdyld program into an
ExecutionEngine support library. Update llvm-rtdyld to just load an object
file into memory, use the library to process it, then run the _main()
function, if one is found.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128031 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127916 91177308-0d34-0410-b5e6-96231b3b80d8
deregisters registered by it FDE structures allowing consecutive
JIT runs to succeed. Patch by Yuri. Fixes PR8285.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117004 91177308-0d34-0410-b5e6-96231b3b80d8
On Mingw and Cygwin, the symbol __main is resolved to
callee's(eg. tools/lli) one, to invoke wrong duplicated ctors
(and register wrong callee's dtors with atexit(3)).
We expect, by callee, ExecutionEngine::runStaticConstructorsDestructors()
is called before ExecutionEngine::runFunctionAsMain() is called.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112474 91177308-0d34-0410-b5e6-96231b3b80d8
exception handling. Also fix an extra underscore typo in one instance of
"__ARM_EABI__". Radar 8236264.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109451 91177308-0d34-0410-b5e6-96231b3b80d8
MachineFunction::DefaultDebugLoc. We now use the same technique as
DwarfDebug::beginFunction to find the starting line number for a
function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102679 91177308-0d34-0410-b5e6-96231b3b80d8
JIT doesn't use the MC back-end asm printer to emit labels that it uses, the
section for the MCSymbol is never set. And thus the MCSymbol for the EH label
isn't marked as "defined". Because of that, TidyLandingPads removes the needed
landing pads from the JIT output. This breaks EH for every JIT program.
This is a work-around for this limitation. We pass in the label locations
map. If the label has a non-zero value, then it was "emitted" by the JIT and
TidyLandingPads shouldn't remove that label.
A nicer solution would be to mark the MCSymbol as "used" by the JIT and not rely
upon the section being set to determine if it's defined or not.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101453 91177308-0d34-0410-b5e6-96231b3b80d8
representation. This eliminates the 'DILocation' MDNodes for
file/line/col tuples from -O0 -g codegen.
This remove the old DebugLoc class, making it a typedef for DebugLoc,
I'll rename NewDebugLoc next.
I didn't update the JIT to use the new apis, so it will continue to
work, but be as slow as before. Someone should eventually do this
or, better yet, rip out the JIT debug info stuff and build the JIT
on top of MC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100209 91177308-0d34-0410-b5e6-96231b3b80d8
instead of label ID's. This cleans up and regularizes a bunch
of code and makes way for future progress.
Unfortunately, this pointed out to me that JITDwarfEmitter.cpp
is largely copy and paste from DwarfException/MachineModuleInfo
and other places. This is very sad and disturbing. :(
One major change here is that TidyLandingPads moved from being
called in DwarfException::BeginFunction to being called in
DwarfException::EndFunction. There should not be any
functionality change from doing this, but I'm not an EH expert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98459 91177308-0d34-0410-b5e6-96231b3b80d8
and add a FIXME about how we are eventually going to zap this
lookup table once mc world domination is complete.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98031 91177308-0d34-0410-b5e6-96231b3b80d8
just count references to it from JIT output to decide when to destroy it. This
patch waits to destroy the JIT's memory of a stub until the Function it refers
to is destroyed. External function stubs and GVIndirectSyms aren't destroyed
until the JIT itself is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97737 91177308-0d34-0410-b5e6-96231b3b80d8
destroyed, it could leave stubs in the StubToResolverMap, which would confuse
the lookup for subsequent lazy compilations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97698 91177308-0d34-0410-b5e6-96231b3b80d8
and T->isPointerTy(). Convert most instances of the first form to the second form.
Requested by Chris.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96344 91177308-0d34-0410-b5e6-96231b3b80d8
the global TheJIT and TheJITResolver variables. Lazy compilation is supported
by a global map from a stub address to the JITResolver that knows how to
compile it.
Patch by Olivier Meurant!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95837 91177308-0d34-0410-b5e6-96231b3b80d8
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().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95390 91177308-0d34-0410-b5e6-96231b3b80d8
1-argument ExecutionEngine::create(Module*) ambiguous with the signature that
used to be ExecutionEngine::create(ModuleProvider*, defaulted_params). Fixed
by removing the 1-argument create(). Fixes PR6221.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95236 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94686 91177308-0d34-0410-b5e6-96231b3b80d8
1. MachineJumpTableInfo is now created lazily for a function the first time
it actually makes a jump table instead of for every function.
2. The encoding of jump table entries is now described by the
MachineJumpTableInfo::JTEntryKind enum. This enum is determined by the
TLI::getJumpTableEncoding() hook, instead of by lots of code scattered
throughout the compiler that "knows" that jump table entries are always
32-bits in pic mode (for example).
3. The size and alignment of jump table entries is now calculated based on
their kind, instead of at machinefunction creation time.
Future work includes using the EntryKind in more places in the compiler,
eliminating other logic that "knows" the layout of jump tables in various
situations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94470 91177308-0d34-0410-b5e6-96231b3b80d8
DebugLocTuple. Also use an AssertingVH to ensure that MDNodes aren't
destroyed while the FilenameCache is using them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94245 91177308-0d34-0410-b5e6-96231b3b80d8
missing ones are libsupport, libsystem and libvmcore. libvmcore is
currently blocked on bugpoint, which uses EH. Once it stops using
EH, we can switch it off.
This #if 0's out 3 unit tests, because gtest requires RTTI information.
Suggestions welcome on how to fix this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94164 91177308-0d34-0410-b5e6-96231b3b80d8
they're available_externally broke VMKit, which was relying on the fact that
functions would only be materialized when they were first called. We'll have
to wait for http://llvm.org/PR5737 to really fix this.
I also added a test for one of the F->isDeclaration() calls which wasn't
covered by anything else in the test suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91943 91177308-0d34-0410-b5e6-96231b3b80d8
argument to runJITOnFunction(), which caused a null pointer dereference at
every call.
Patch by Gianluca Guida!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91939 91177308-0d34-0410-b5e6-96231b3b80d8
remove start/finishGVStub and the BufferState helper class from the
MachineCodeEmitter interface. It has the side-effect of not setting the
indirect global writable and then executable on ARM, but that shouldn't be
necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91464 91177308-0d34-0410-b5e6-96231b3b80d8
isPodLike type trait. This is a generally useful type trait for
more than just DenseMap, and we really care about whether something
acts like a pod, not whether it really is a pod.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91421 91177308-0d34-0410-b5e6-96231b3b80d8
nlewycky's fix to add -rdynamic so the JIT can look symbols up in Linux builds
of the JITTests binary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91250 91177308-0d34-0410-b5e6-96231b3b80d8
This code was crashing always with oprofile enabled, since it tried to create a StringRef
out of NULL, which run strlen on NULL.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91046 91177308-0d34-0410-b5e6-96231b3b80d8
way for each TargetJITInfo subclass to allocate its own stubs. This
means stubs aren't as exactly-sized anymore, but it lets us get rid of
TargetJITInfo::emitFunctionStubAtAddr(), which lets ARM and PPC
support the eager JIT, fixing http://llvm.org/PR4816.
* Rename the JITEmitter's stub creation functions to describe the kind
of stub they create. So far, all of them create lazy-compilation
stubs, but they sometimes get used when far-call stubs are needed.
Fixing http://llvm.org/PR5201 will involve fixing this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89715 91177308-0d34-0410-b5e6-96231b3b80d8
It's probably better in the long run to replace the
indirect-GlobalVariable system. That'll be done after a subsequent
patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89708 91177308-0d34-0410-b5e6-96231b3b80d8
libffi support and that the interpreter can't call external functions without
it. Patch by Timo Juhani Lindfors! Fixes PR5466.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89062 91177308-0d34-0410-b5e6-96231b3b80d8
The large code model is documented at
http://www.x86-64.org/documentation/abi.pdf and says that calls should
assume their target doesn't live within the 32-bit pc-relative offset
that fits in the call instruction.
To do this, we turn off the global-address->target-global-address
conversion in X86TargetLowering::LowerCall(). The first attempt at
this broke the lazy JIT because it can separate the movabs(imm->reg)
from the actual call instruction. The lazy JIT receives the address of
the movabs as a relocation and needs to record the return address from
the call; and then when that call happens, it needs to patch the
movabs with the newly-compiled target. We could thread the call
instruction into the relocation and record the movabs<->call mapping
explicitly, but that seems to require at least as much new
complication in the code generator as this change.
To fix this, we make lazy functions _always_ go through a call
stub. You'd think we'd only have to force lazy calls through a stub on
difficult platforms, but that turns out to break indirect calls
through a function pointer. The right fix for that is to distinguish
between calls and address-of operations on uncompiled functions, but
that's complex enough to leave for someone else to do.
Another attempt at this defined a new CALL64i pseudo-instruction,
which expanded to a 2-instruction sequence in the assembly output and
was special-cased in the X86CodeEmitter's emitInstruction()
function. That broke indirect calls in the same way as above.
This patch also removes a hack forcing Darwin to the small code model.
Without far-call-stubs, the small code model requires things of the
JITMemoryManager that the DefaultJITMemoryManager can't provide.
Thanks to echristo for lots of testing!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88984 91177308-0d34-0410-b5e6-96231b3b80d8
MachineRelocations, "stub" always refers to a far-call stub or a
load-a-faraway-global stub, so this patch adds "Far" to the term. (Other stubs
are used for lazy compilation and dlsym address replacement.) The variable was
also inconsistent between the positive and negative sense, and the positive
sense ("NeedStub") was more demanding than is accurate (since a nearby-enough
function can be called directly even if the platform often requires a stub).
Since the negative sense causes double-negatives, I switched to
"MayNeedFarStub" globally.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86363 91177308-0d34-0410-b5e6-96231b3b80d8
of going through the global TheJIT variable. This makes it easier to use
features of JITEmitter that aren't in JITCodeEmitter for fixing PR5201.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86305 91177308-0d34-0410-b5e6-96231b3b80d8
now correctly runs clang's test/CodeGen/indirect-goto.c. The JIT will abort
on it until someone feels compelled to implement this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85488 91177308-0d34-0410-b5e6-96231b3b80d8
being destroyed. This allows users to run global optimizations like globaldce
even after some functions have been jitted.
This patch also removes the Function* parameter to
JITEventListener::NotifyFreeingMachineCode() since it can cause that to be
called when the Function is partially destroyed. This change will be even more
helpful later when I think we'll want to allow machine code to actually outlive
its Function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85182 91177308-0d34-0410-b5e6-96231b3b80d8
Remove LowerAllocations pass.
Update some more passes to treate free calls just like they were treating FreeInst.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85176 91177308-0d34-0410-b5e6-96231b3b80d8
compiled.
When functions are compiled, they accumulate references in the JITResolver's
stub maps. This patch removes those references when the functions are
destroyed. It's illegal to destroy a Function when any thread may still try to
call its machine code.
This patch also updates r83987 to use ValueMap instead of explicit CallbackVHs
and fixes a couple "do stuff inside assert()" bugs from r84522.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84975 91177308-0d34-0410-b5e6-96231b3b80d8
JITEmitter.
I'm gradually making Functions auto-remove themselves from the JIT when they're
destroyed. In this case, the Function needs to be removed from the JITEmitter,
but the map recording which Functions need to be removed lived behind the
JITMemoryManager interface, which made things difficult.
This patch replaces the deallocateMemForFunction(Function*) method with a pair
of methods deallocateFunctionBody(void *) and deallocateExceptionTable(void *)
corresponding to the two startFoo/endFoo pairs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84651 91177308-0d34-0410-b5e6-96231b3b80d8
The JITResolver maps Functions to their canonical stubs and all callsites for
lazily-compiled functions to their target Functions. To make Function
destruction work, I'm going to need to remove all callsites on destruction, so
this patch also adds the reverse mapping for that.
There was an incorrect assumption in here that the only stub for a function
would be the one caused by needing to lazily compile it, while x86-64 far calls
and dlsym-stubs could also cause such stubs, but I didn't look for a test case
that the assumption broke.
This also adds DenseMapInfo<AssertingVH> so I can use DenseMaps instead of
std::maps.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84522 91177308-0d34-0410-b5e6-96231b3b80d8
GlobalValue is destroyed. Function destruction still leaks machine code and
can crash on leaked stubs, but this is some progress.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83987 91177308-0d34-0410-b5e6-96231b3b80d8
mappings, which could cause errors and assert-failures. This patch fixes that,
adds a test, and refactors the global-mapping-removal code into a single place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83678 91177308-0d34-0410-b5e6-96231b3b80d8
the new predicates I added) instead of going through a context and doing a
pointer comparison. Besides being cheaper, this allows a smart compiler
to turn the if sequence into a switch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83297 91177308-0d34-0410-b5e6-96231b3b80d8
By the way, this code is buggy. You can't keep a map<MDNode *, something>
because the MDNode may be destroyed and reused for something else.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83141 91177308-0d34-0410-b5e6-96231b3b80d8
feature, either build the JIT in debug mode to enable it by default or pass
-jit-emit-debug to lli.
Right now, the only debug information that this communicates to GDB is call
frame information, since it's already being generated to support exceptions in
the JIT. Eventually, when DWARF generation isn't tied so tightly to AsmPrinter,
it will be easy to push that information to GDB through this interface.
Here's a step-by-step breakdown of how the feature works:
- The JIT generates the machine code and DWARF call frame info
(.eh_frame/.debug_frame) for a function into memory.
- The JIT copies that info into an in-memory ELF file with a symbol for the
function.
- The JIT creates a code entry pointing to the ELF buffer and adds it to a
linked list hanging off of a global descriptor at a special symbol that GDB
knows about.
- The JIT calls a function marked noinline that GDB knows about and has put an
internal breakpoint in.
- GDB catches the breakpoint and reads the global descriptor to look for new
code.
- When sees there is new code, it reads the ELF from the inferior's memory and
adds it to itself as an object file.
- The JIT continues, and the next time we stop the program, we are able to
produce a proper backtrace.
Consider running the following program through the JIT:
#include <stdio.h>
void baz(short z) {
long w = z + 1;
printf("%d, %x\n", w, *((int*)NULL)); // SEGFAULT here
}
void bar(short y) {
int z = y + 1;
baz(z);
}
void foo(char x) {
short y = x + 1;
bar(y);
}
int main(int argc, char** argv) {
char x = 1;
foo(x);
}
Here is a backtrace before this patch:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2aaaabdfbd10 (LWP 25476)]
0x00002aaaabe7d1a8 in ?? ()
(gdb) bt
#0 0x00002aaaabe7d1a8 in ?? ()
#1 0x0000000000000003 in ?? ()
#2 0x0000000000000004 in ?? ()
#3 0x00032aaaabe7cfd0 in ?? ()
#4 0x00002aaaabe7d12c in ?? ()
#5 0x00022aaa00000003 in ?? ()
#6 0x00002aaaabe7d0aa in ?? ()
#7 0x01000002abe7cff0 in ?? ()
#8 0x00002aaaabe7d02c in ?? ()
#9 0x0100000000000001 in ?? ()
#10 0x00000000014388e0 in ?? ()
#11 0x00007fff00000001 in ?? ()
#12 0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70,
F=0x14024e0, ArgValues=@0x7fffffffe050)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395
#13 0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain
(this=0x1405b70, Fn=0x14024e0, argv=@0x13f06f8, envp=0x7fffffffe3b0)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377
#14 0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe398,
envp=0x7fffffffe3b0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208
And a backtrace after this patch:
Program received signal SIGSEGV, Segmentation fault.
0x00002aaaabe7d1a8 in baz ()
(gdb) bt
#0 0x00002aaaabe7d1a8 in baz ()
#1 0x00002aaaabe7d12c in bar ()
#2 0x00002aaaabe7d0aa in foo ()
#3 0x00002aaaabe7d02c in main ()
#4 0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70,
F=0x14024e0, ArgValues=...)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395
#5 0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain
(this=0x1405b70, Fn=0x14024e0, argv=..., envp=0x7fffffffe3c0)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377
#6 0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe3a8,
envp=0x7fffffffe3c0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82418 91177308-0d34-0410-b5e6-96231b3b80d8