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.
llvm-svn: 131317
actually takes rather than how much memory was allocated for it. This
is more accurate and should help the manager pack things more effectively.
llvm-svn: 131305
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.
llvm-svn: 131243
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.
llvm-svn: 131026
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.
llvm-svn: 130395
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
$
llvm-svn: 129388
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.
llvm-svn: 129307
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.
llvm-svn: 129138
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.
llvm-svn: 128973
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.
llvm-svn: 128851
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.
llvm-svn: 128171
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.
llvm-svn: 128090
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.
llvm-svn: 128052
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.
llvm-svn: 128031
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
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.
llvm-svn: 112474
MachineFunction::DefaultDebugLoc. We now use the same technique as
DwarfDebug::beginFunction to find the starting line number for a
function.
llvm-svn: 102679
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.
llvm-svn: 101453
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.
llvm-svn: 100209
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.
llvm-svn: 98459
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.
llvm-svn: 97737
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!
llvm-svn: 95837
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
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.
llvm-svn: 95236
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
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.
llvm-svn: 94470
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.
llvm-svn: 94164
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.
llvm-svn: 91943
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.
llvm-svn: 91464
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.
llvm-svn: 91421
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.
llvm-svn: 89715
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!
llvm-svn: 88984
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.
llvm-svn: 86363
of going through the global TheJIT variable. This makes it easier to use
features of JITEmitter that aren't in JITCodeEmitter for fixing PR5201.
llvm-svn: 86305
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
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.
llvm-svn: 85182
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.
llvm-svn: 84975
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.
llvm-svn: 84651
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.
llvm-svn: 84522
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.
llvm-svn: 83678
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.
llvm-svn: 83297
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.
llvm-svn: 83141
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
llvm-svn: 82418
desired triplet is a sub-target, e.g. thumbv7 vs. arm host). Reverting the
patch isn't quite right either since the previous behavior does not allow the
triplet to be overridden with -march.
llvm-svn: 80742
members that call methods that read the PoisonMemory member.
This fixes potential spurious (though probably otherwise
harmless) poising of unused memory, and fixes the
associated valgrind error.
llvm-svn: 80192
bytes. libgcc doesn't seem to mind, but if you pass this DWARF to GDB, it
doesn't like it.
Also make the JIT memory manager to initialize it's memory to garbage in debug
mode, so that it's easier to find bugs like these in the future.
llvm-svn: 79674
and short. Well, it's kinda short. Definitely nasty and brutish.
The front-end generates the register/unregister calls into the SjLj runtime,
call-site indices and landing pad dispatch. The back end fills in the LSDA
with the call-site information provided by the front end. Catch blocks are
not yet implemented.
Built on Darwin and verified no llvm-core "make check" regressions.
llvm-svn: 78625
http://llvm.org/viewvc/llvm-project?view=rev&revision=78127, I'm changing the
ExecutionEngine's global mappings to hold AssertingVH<const GlobalValue>. That
way, if unregistering a mapping fails to actually unregister it, we'll get an
assert. Running the jit nightly tests didn't uncover any actual instances of
the problem.
This also uncovered the fact that AssertingVH<const X> didn't work, so I fixed
that too.
llvm-svn: 78400
This is not just a matter of passing in the target triple from the module;
currently backends are making decisions based on the build and host
architecture. The goal is to migrate to making these decisions based off of the
triple (in conjunction with the feature string). Thus most clients pass in the
target triple, or the host triple if that is empty.
This has one important change in the way behavior of the JIT and llc.
For the JIT, it was previously selecting the Target based on the host
(naturally), but it was setting the target machine features based on the triple
from the module. Now it is setting the target machine features based on the
triple of the host.
For LLC, -march was previously only used to select the target, the target
machine features were initialized from the module's triple (which may have been
empty). Now the target triple is taken from the module, or the host's triple is
used if that is empty. Then the triple is adjusted to match -march.
The take away is that -march for llc is now used in conjunction with the host
triple to initialize the subtarget. If users want more deterministic behavior
from llc, they should use -mtriple, or set the triple in the input module.
llvm-svn: 77946
- Instead of requiring targets to define a JIT quality match function, we just
have them specify if they support a JIT.
- Target selection for the JIT just gets the host triple and looks for the best
target which matches the triple and has a JIT.
llvm-svn: 77060
- Some clients which used DOUT have moved to DEBUG. We are deprecating the
"magic" DOUT behavior which avoided calling printing functions when the
statement was disabled. In addition to being unnecessary magic, it had the
downside of leaving code in -Asserts builds, and of hiding potentially
unnecessary computations.
llvm-svn: 77019
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
call to the MachineCodeEmitter interface and made copying the start
line of a function not conditional on whether we're emitting Dwarf
debug information. I'll propagate the processDebugLoc() calls to the
non-X86 targets in a followup patch.
In the long run, it'll probably be better to gather this information
through the DwarfWriter, but the DwarfWriter currently depends on the
AsmPrinter and TargetAsmInfo, and fixing that would be out of the way
for this patch.
There's a bug in OProfile 0.9.4 that makes it ignore line numbers for
addresses above 4G, and a patch fixing it at
http://thread.gmane.org/gmane.linux.oprofile/7634
Sample output:
$ sudo opcontrol --reset; sudo opcontrol --start-daemon; sudo opcontrol --start; `pwd`/Debug/bin/lli fib.bc; sudo opcontrol --stop
Signalling daemon... done
Profiler running.
fib(40) == 165580141
Stopping profiling.
$ opreport -g -d -l `pwd`/Debug/bin/lli|head -60
Overflow stats not available
CPU: Core 2, speed 1998 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
vma samples % linenr info image name symbol name
00007f67a30370b0 25489 61.2554 fib.c:24 10946.jo fib_left
00007f67a30370b0 1634 6.4106 fib.c:24
00007f67a30370b1 83 0.3256 fib.c:24
00007f67a30370b9 1997 7.8348 fib.c:24
00007f67a30370c6 2080 8.1604 fib.c:27
00007f67a30370c8 988 3.8762 fib.c:27
00007f67a30370cd 1315 5.1591 fib.c:27
00007f67a30370cf 251 0.9847 fib.c:27
00007f67a30370d3 1191 4.6726 fib.c:27
00007f67a30370d6 975 3.8252 fib.c:27
00007f67a30370db 1010 3.9625 fib.c:27
00007f67a30370dd 242 0.9494 fib.c:27
00007f67a30370e1 2782 10.9145 fib.c:28
00007f67a30370e5 3768 14.7828 fib.c:28
00007f67a30370eb 615 2.4128 (no location information)
00007f67a30370f3 6558 25.7287 (no location information)
00007f67a3037100 15603 37.4973 fib.c:29 10946.jo fib_right
00007f67a3037100 1646 10.5493 fib.c:29
00007f67a3037101 45 0.2884 fib.c:29
00007f67a3037109 2372 15.2022 fib.c:29
00007f67a3037116 2234 14.3178 fib.c:32
00007f67a3037118 612 3.9223 fib.c:32
00007f67a303711d 622 3.9864 fib.c:32
00007f67a303711f 385 2.4675 fib.c:32
00007f67a3037123 404 2.5892 fib.c:32
00007f67a3037126 634 4.0633 fib.c:32
00007f67a303712b 870 5.5759 fib.c:32
00007f67a303712d 62 0.3974 fib.c:32
00007f67a3037131 1848 11.8439 fib.c:33
00007f67a3037135 2840 18.2016 fib.c:33
00007f67a303713a 1 0.0064 fib.c:33
00007f67a303713b 1023 6.5564 (no location information)
00007f67a3037143 5 0.0320 (no location information)
000000000080c1e4 15 0.0360 MachineOperand.h:150 lli llvm::MachineOperand::isReg() const
000000000080c1e4 6 40.0000 MachineOperand.h:150
000000000080c1ec 2 13.3333 MachineOperand.h:150
...
llvm-svn: 76102
--- Reverse-merging r75799 into '.':
U test/Analysis/PointerTracking
U include/llvm/Target/TargetMachineRegistry.h
U include/llvm/Target/TargetMachine.h
U include/llvm/Target/TargetRegistry.h
U include/llvm/Target/TargetSelect.h
U tools/lto/LTOCodeGenerator.cpp
U tools/lto/LTOModule.cpp
U tools/llc/llc.cpp
U lib/Target/PowerPC/PPCTargetMachine.h
U lib/Target/PowerPC/AsmPrinter/PPCAsmPrinter.cpp
U lib/Target/PowerPC/PPCTargetMachine.cpp
U lib/Target/PowerPC/PPC.h
U lib/Target/ARM/ARMTargetMachine.cpp
U lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp
U lib/Target/ARM/ARMTargetMachine.h
U lib/Target/ARM/ARM.h
U lib/Target/XCore/XCoreTargetMachine.cpp
U lib/Target/XCore/XCoreTargetMachine.h
U lib/Target/PIC16/PIC16TargetMachine.cpp
U lib/Target/PIC16/PIC16TargetMachine.h
U lib/Target/Alpha/AsmPrinter/AlphaAsmPrinter.cpp
U lib/Target/Alpha/AlphaTargetMachine.cpp
U lib/Target/Alpha/AlphaTargetMachine.h
U lib/Target/X86/X86TargetMachine.h
U lib/Target/X86/X86.h
U lib/Target/X86/AsmPrinter/X86ATTAsmPrinter.h
U lib/Target/X86/AsmPrinter/X86AsmPrinter.cpp
U lib/Target/X86/AsmPrinter/X86IntelAsmPrinter.h
U lib/Target/X86/X86TargetMachine.cpp
U lib/Target/MSP430/MSP430TargetMachine.cpp
U lib/Target/MSP430/MSP430TargetMachine.h
U lib/Target/CppBackend/CPPTargetMachine.h
U lib/Target/CppBackend/CPPBackend.cpp
U lib/Target/CBackend/CTargetMachine.h
U lib/Target/CBackend/CBackend.cpp
U lib/Target/TargetMachine.cpp
U lib/Target/IA64/IA64TargetMachine.cpp
U lib/Target/IA64/AsmPrinter/IA64AsmPrinter.cpp
U lib/Target/IA64/IA64TargetMachine.h
U lib/Target/IA64/IA64.h
U lib/Target/MSIL/MSILWriter.cpp
U lib/Target/CellSPU/SPUTargetMachine.h
U lib/Target/CellSPU/SPU.h
U lib/Target/CellSPU/AsmPrinter/SPUAsmPrinter.cpp
U lib/Target/CellSPU/SPUTargetMachine.cpp
U lib/Target/Mips/AsmPrinter/MipsAsmPrinter.cpp
U lib/Target/Mips/MipsTargetMachine.cpp
U lib/Target/Mips/MipsTargetMachine.h
U lib/Target/Mips/Mips.h
U lib/Target/Sparc/AsmPrinter/SparcAsmPrinter.cpp
U lib/Target/Sparc/SparcTargetMachine.cpp
U lib/Target/Sparc/SparcTargetMachine.h
U lib/ExecutionEngine/JIT/TargetSelect.cpp
U lib/Support/TargetRegistry.cpp
llvm-svn: 75820
- They still use the TargetMachineRegistry to populate the contents of the
-march option (via the listener interface). We can't just populate it in the
option parser because we can't expect the TargetRegistry to be populated yet
(we no longer rely on static constructors).
- There are a couple ways to finish killing off TargetMachineRegistry, but I
haven't figured out the cleanest one yet...
llvm-svn: 75773
This adds location info for all llvm_unreachable calls (which is a macro now) in
!NDEBUG builds.
In NDEBUG builds location info and the message is off (it only prints
"UREACHABLE executed").
llvm-svn: 75640
Make llvm_unreachable take an optional string, thus moving the cerr<< out of
line.
LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for
NDEBUG builds.
llvm-svn: 75379
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
default, this option is not enabled to support clients who rely on
this behavior.
Fixes http://llvm.org/PR4483
A patch to allocate additional memory for globals after we run out is
forthcoming.
Patch by Reid Kleckner!
llvm-svn: 75059
This will replace exit()/abort() style error handling with an API
that allows clients to register custom error handling hooks.
The default is to call exit(1) when no error handler is provided.
llvm-svn: 74922
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
libraries instead of relinked objects, the interpreter, JIT, and native
target libraries were not being linked in to an ocaml program using the
ExecutionEngine.
llvm-svn: 74117
integer and floating-point opcodes, introducing
FAdd, FSub, and FMul.
For now, the AsmParser, BitcodeReader, and IRBuilder all preserve
backwards compatability, and the Core LLVM APIs preserve backwards
compatibility for IR producers. Most front-ends won't need to change
immediately.
This implements the first step of the plan outlined here:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt
llvm-svn: 72897
Introduce a new class (MachineCodeInfo) that the JIT can fill in with details. Right now, just the address and the size of the machine code are reported.
Patch by Evan Phoenix!
llvm-svn: 72040
another stub, but then never calling the jitted function) can cause the JIT to
leave a stub in place. Judging by the comments this is a known deficiency, so
we're just not going to use AssertingVH for the StubToFunctionTy map.
Also shorten some lines longer than 80 columns.
This fixes the "make check" failure with ocaml on x86-64 linux.
llvm-svn: 70185
Evan Cheng