It is not safe to call LegalizeOp on something that has already been legalized.
Instead, just force another iteration of legalization.
This could affect all platforms but X86, as this codepath is dynamically
dead on X86 (ISD::MEMSET and friends are legal).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22419 91177308-0d34-0410-b5e6-96231b3b80d8
JIT can run against a multi-threaded program without getting its data
structures messed up. Also had to add the examples directory to the path
for the tests so that ParallelJIT can be found.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22415 91177308-0d34-0410-b5e6-96231b3b80d8
Add an example program that utilizes multiple threads in the JIT to process
work. This was used by Evan Jones as the original test case for ensuring
that the ExecutionEngine was thread safe.
Original source by Evan Jones (adapted from other LLVM JIT examples) and
made LLVM style compliant by Reid Spencer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22411 91177308-0d34-0410-b5e6-96231b3b80d8
This patch completes the changes for making lli thread-safe. Here's the list
of changes:
* The Support/ThreadSupport* files were removed and replaced with the
MutexGuard.h file since all ThreadSupport* declared was a Mutex Guard.
The implementation of MutexGuard.h is now based on sys::Mutex which hides
its implementation and makes it unnecessary to have the -NoSupport.h and
-PThreads.h versions of ThreadSupport.
* All places in ExecutionEngine that previously referred to "Mutex" now
refer to sys::Mutex
* All places in ExecutionEngine that previously referred to "MutexLocker"
now refer to MutexGuard (this is frivolous but I believe the technically
correct name for such a class is "Guard" not a "Locker").
These changes passed all of llvm-test. All we need now are some test cases
that actually use multiple threads.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22404 91177308-0d34-0410-b5e6-96231b3b80d8
Add a Mutex class for thread synchronization in a platform-independent way.
The current implementation only supports pthreads. Win32 use of Critical
Sections will be added later. The design permits other threading models to
be used if (and only if) pthreads is not available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22403 91177308-0d34-0410-b5e6-96231b3b80d8
Make sure that -lpthread gets added to LIBS variable which puts it at the
end of the tools' link commands, if libpthread.a is found.
Add a test for pthread.h so we can use #ifdef HAVE_PTHREAD_H
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22401 91177308-0d34-0410-b5e6-96231b3b80d8
Implement the X86 Subtarget.
This consolidates the checks for target triple, and setting options based
on target triple into one place. This allows us to convert the asm printer
and isel over from being littered with "forDarwin", "forCygwin", etc. into
just having the appropriate flags for each subtarget feature controlling
the code for that feature.
This patch also implements indirect external and weak references in the
X86 pattern isel, for darwin. Next up is to convert over the asm printers
to use this new interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22389 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of emitting a JIT stub that looks like this:
internal void %l1_main_entry_2E_ce_wrapper(int) {
header:
%resolver = call sbyte* %getPointerToNamedFunction( sbyte* getelementptr ([20 x sbyte]* %l1_main_entry_2E_ce_name, int 0, int 0) ) ; <sbyte*> [#uses=1]
%resolverCast = cast sbyte* %resolver to void (int)* ; <void (int)*> [#uses=1]
call void %resolverCast( int %0 )
ret void
}
Emit one that looks like this:
internal void %l1_main_entry_2E_ce_wrapper(int) {
Entry:
%fpcache = load void (int)** %l1_main_entry_2E_ce.fpcache ; <void (int)*> [#uses=2]
%isNull = seteq void (int)* %fpcache, null ; <bool> [#uses=1]
br bool %isNull, label %lookupfp, label %usecache
usecache: ; preds = %lookupfp, %Entry
%fp = phi void (int)* [ %resolverCast, %lookupfp ], [ %fpcache, %Entry ] ; <void (int)*> [#uses=1]
call void %fp( int %0 )
ret void
lookupfp: ; preds = %Entry
%resolver = call sbyte* %getPointerToNamedFunction( sbyte* getelementptr ([20 x sbyte]* %l1_main_entry_2E_ce_name, int 0, int 0) ) ; <sbyte*> [#uses=1]
%resolverCast = cast sbyte* %resolver to void (int)* ; <void (int)*> [#uses=2]
store void (int)* %resolverCast, void (int)** %l1_main_entry_2E_ce.fpcache
br label %usecache
}
This makes the JIT debugger *MUCH* faster on large programs, as
getPointerToNamedFunction takes time linear with the size of the program, and
before we would call it every time a function in the text module was called from
the safe module (ouch!).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22387 91177308-0d34-0410-b5e6-96231b3b80d8
allows objdump to know which function we are emitting to:
00000000 <foo>: <----
0: b8 01 00 00 00 mov $0x1,%eax
5: 03 44 24 04 add 0x4(%esp,1),%eax
9: c3 ret
... and allows .o files to be useful for linking :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22378 91177308-0d34-0410-b5e6-96231b3b80d8
Add a *VERY INITIAL* machine code emitter class. This is enough to take
this C function:
int foo(int X) { return X +1; }
and make objdump produce the following:
$ objdump -d t-llvm.o
t-llvm.o: file format elf32-i386
Disassembly of section .text:
00000000 <.text>:
0: b8 01 00 00 00 mov $0x1,%eax
5: 03 44 24 04 add 0x4(%esp,1),%eax
9: c3 ret
Anything using branches or refering to the constant pool or requiring
relocations will not work yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22375 91177308-0d34-0410-b5e6-96231b3b80d8
This is the last MVTSDNode.
This allows us to eliminate a bunch of special case code for handling
MVTSDNodes.
Also, remove some uses of dyn_cast that should really be cast (which is
cheaper in a release build).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22368 91177308-0d34-0410-b5e6-96231b3b80d8
This is the last MVTSDNode.
This allows us to eliminate a bunch of special case code for handling
MVTSDNodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22367 91177308-0d34-0410-b5e6-96231b3b80d8
