api's look like this:

ModuleProvider *getBytecodeModuleProvider(
  const std::string &Filename,  ///< Name of file to be read
  BCDecompressor_t *BCDC = Compressor::decompressToNewBuffer,
  std::string* ErrMsg = 0,      ///< Optional error message holder
  BytecodeHandler* H = 0        ///< Optional handler for reader events
);

This is ugly, but allows a client to say:

  getBytecodeModuleProvider("foo", 0);

If they do this, there is no dependency on the compression libraries, saving
codesize.

llvm-svn: 34012

Adjust to changes in Module interface:
getMainFunction() -> getFunction("main")
getNamedFunction(X) -> getFunction(X)

llvm-svn: 33922

This patch replaces the SymbolTable class with ValueSymbolTable which does
not support types planes. This means that all symbol names in LLVM must now
be unique. The patch addresses the necessary changes to deal with this and
removes code no longer needed as a result. This completes the bulk of the
changes for this PR. Some cleanup patches will follow.

llvm-svn: 33918

llvm-svn: 33873

llvm-svn: 33872

llvm-svn: 33871

llvm-svn: 33870

llvm-svn: 33756

confusion with external linkage types.

llvm-svn: 33663

llvm-svn: 33611

llvm-svn: 33610

The Module::setEndianness and Module::setPointerSize methods have been
removed. Instead you can get/set the DataLayout. Adjust thise accordingly.

llvm-svn: 33530

Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.

This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
   bits in an integer. The Type classes SubclassData field is used to
   store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
   64-bit integers. These are replaced with just IntegerType which is not
   a primitive any more.
3. Adjust the rest of LLVM to account for this change.

Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types.  Future increments
will rectify this situation.

llvm-svn: 33113

Take an incremental step towards type plane elimination. This change
separates types from values in the symbol tables by finally making use
of the TypeSymbolTable class. This yields more natural interfaces for
dealing with types and unclutters the SymbolTable class.

llvm-svn: 32956

llvm-svn: 32603

llvm-svn: 32469

llvm-svn: 32340

now cerr, cout, and NullStream resp.

llvm-svn: 32298

llvm-svn: 32052

llvm-svn: 31936

llvm-svn: 31687

Fix an infinite loop in the Linker and a few other assorted link problems.

Patch contributed by Scott Michel. Thanks, Scott!

llvm-svn: 31680

llvm-svn: 31587

Turn on -Wunused and -Wno-unused-parameter. Clean up most of the resulting
fall out by removing unused variables. Remaining warnings have to do with
unused functions (I didn't want to delete code without review) and unused
variables in generated code. Maintainers should clean up the remaining
issues when they see them. All changes pass DejaGnu tests and Olden.

llvm-svn: 31380

DLL* linkages got full (I hope) codegeneration support in C & both x86
assembler backends.
External weak linkage added for future use, we don't provide any
codegeneration, etc. support for it.

llvm-svn: 30374

llvm-svn: 29405

llvm-svn: 29149

in lib/Bytecode/Archive/Makefile is now removed. One small step closer to
a smaller LLVM.

llvm-svn: 29067

llvm-svn: 28812

llvm-svn: 28640

llvm-svn: 27515

Instruction::InsertElement.

llvm-svn: 27477

llvm-svn: 25571

llvm-svn: 25560

llvm-svn: 25467

llvm-svn: 25414

With these patches we implement the ability for the Linker library to
keep track of which libraries were actually bytecode files (not archives)
and cause their users to remove such files from the list of libraries to
pass to the native linker.

llvm-svn: 25169

llvm-svn: 25168

the module being constructed. This is used to correctly name the module.
Previously the name of the linker tool was used which produces confusing
output when the module identifier is used in an error message.

llvm-svn: 24699

PR662.  Thanks to Markus for providing me with a ton of files to
reproduce the problem!

llvm-svn: 24619