delete ParseBytecodeFile(InputFilename, 0, &ErrorMessage);
llvm_shutdown();
delete ParseBytecodeFile(InputFilename, 0, &ErrorMessage);
The primitive type objects failed to ressurect themselves after shutdown, leading
to crashes in clients that used them after llvm_shutdown().
This solution isn't wonderful, because we clearly have static ctors. However,
the code it replaces was just as bad, so it's not a regression.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34106 91177308-0d34-0410-b5e6-96231b3b80d8
2. All function-level constants are now incorporated into the module-level
constant pool, since the compaction table was removed. Eliminate extra
work to check for them.
This speeds up the bcwriter from 24.4s to 13.1s on 447.dealII and .73 -> .56s
on kc++ in a release build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34084 91177308-0d34-0410-b5e6-96231b3b80d8
add some signed/unsigned arithmetic operation functions into APInt.h to
handle the signed/unsigned issue. These functions will be defined inside a
namespace "APIntOps" which is inside llvm namespace.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34053 91177308-0d34-0410-b5e6-96231b3b80d8
The code sequence before the spiller is something like:
= tMOVrr
%reg1117 = tMOVrr
%reg1078 = tLSLri %reg1117, 2
The it starts spilling:
%r0 = tRestore <fi#5>, 0
%r1 = tRestore <fi#7>, 0
%r1 = tMOVrr %r1<kill>
tSpill %r1, <fi#5>, 0
%reg1078 = tLSLri %reg1117, 2
It restores the value while processing the first tMOVrr. At this point, the
spiller remembers fi#5 is available in %r0. Next it processes the second move.
It restores the source before the move and spills the result afterwards. The
move becomes a noop and is deleted. However, a spill has been inserted and that
should invalidate reuse of %r0 for fi#5 and add reuse of %r1 for fi#5.
Therefore, %reg1117 (which is also assigned fi#5) should get %r1, not %r0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34039 91177308-0d34-0410-b5e6-96231b3b80d8
definition of it into the CodeGen library. This is so that a backend doesn't
necessarily add in these writers if it doesn't use them (like in the lli
program).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34034 91177308-0d34-0410-b5e6-96231b3b80d8
do some common stuff, then on our own add an object file writer (by calling
a concrete function), and then do some finishing stuff, if need be.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34032 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34012 91177308-0d34-0410-b5e6-96231b3b80d8
to construct FunctionType in separate function, and, have getDeclaration
return a Function instead of a Constant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34008 91177308-0d34-0410-b5e6-96231b3b80d8
This happened because deadargelim now causes VMCore to auto-rename every
function that it hacks arguments out of. Because it hacks arguments out of
functions in a non-deterministic order, this caused the resultant numbering
to be nondet. The fix is to just be careful to not rename functions!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34005 91177308-0d34-0410-b5e6-96231b3b80d8
that is the case, whenever we use it as a scratch register, save it to R12
first and then restore it after the use.
This is a temporary and truly horrible workaround!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33999 91177308-0d34-0410-b5e6-96231b3b80d8
- If there is a dynamic alloca, in the epilogue, restore the value of sp
using r7 - offset.
- Other bug fixes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33997 91177308-0d34-0410-b5e6-96231b3b80d8
