llvm-svn: 28069

llvm-svn: 28066

1. Change several methods in the MachineCodeEmitter class to be pure virtual.
2. Suck emitConstantPool/initJumpTableInfo into startFunction, removing them
   from the MachineCodeEmitter interface, and reducing the amount of target-
   specific code.
3. Change the JITEmitter so that it allocates constantpools and jump tables
   *right* next to the functions that they belong to, instead of in a separate
   pool of memory.  This makes all memory for a function be contiguous, and
   means the JITEmitter only tracks one block of memory now.

llvm-svn: 28065

just have the JIT malloc them.

llvm-svn: 28062

llvm-svn: 28061

code emission location into the base class, instead of being in the derived classes.

This change means that low-level methods like emitByte/emitWord now are no longer
virtual (yaay for speed), and we now have a framework to support growable code
segments.  This implements feature request #1 of PR469.

llvm-svn: 28059

llvm-svn: 28055

llvm-svn: 27967

x86 and ppc for 100% dense switch statements when relocations are non-PIC.
This support will be extended and enhanced in the coming days to support
PIC, and less dense forms of jump tables.

llvm-svn: 27947

llvm-svn: 26079

value/alignment pair for each constant, keep a value/offset pair.

llvm-svn: 26078

llvm-svn: 26076

llvm-svn: 25855

llvm-svn: 25516

llvm-svn: 25140

llvm-svn: 22568

llvm-svn: 22565

llvm-svn: 22554

near the GOT, which new doesn't do.  So break out the allocate into a new function.

Also move GOT index handling into JITResolver.  This lets it update the mapping when a Lazy
function is JITed.  It doesn't managed the table, just the mapping.  Note that this is
still non-ideal, as any function that takes a function address should also take a GOT
index, but that is a lot of changes.  The relocation resolve process updates any GOT entry
it sees is out of date.

llvm-svn: 22537

llvm-svn: 22523

llvm-svn: 22513

the JIT memory manager will construct a GOT if you want it too.  Also, it places the constants in the allocated memory, rather than a malloc area

llvm-svn: 22497

llvm-svn: 22480

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.

llvm-svn: 22404

llvm-svn: 21440

llvm-svn: 21422

llvm-svn: 21313

Bill Wendling!!

llvm-svn: 20649

ANY program that does not have all functions internalized.

llvm-svn: 20258

leaked to the system.  Now they are destroyed with the JITMemoryManager is
destroyed.

llvm-svn: 19434

llvm-svn: 19390

Patch contributed by Morten Ofsted.

llvm-svn: 18889

llvm-svn: 18537

llvm-svn: 18405

llvm-svn: 18391

llvm-svn: 18132

llvm-svn: 18131

llvm-svn: 18129

llvm-svn: 18098

llvm-svn: 18081