DynamicLibrary::SearchForAddressOfSymbol and force them to have "C"
linkage.
Interestingly, GCC treats the block-scoped "extern" declarations we
previously had as if they were extern "C" declarations (or, at least,
were in the global namespace), so that GCC bug papered over this LLVM
bug. Clang and EDG get the linkage correct; this new variant seems to
work for both GCC and Clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92020 91177308-0d34-0410-b5e6-96231b3b80d8
simply passes output to errs(). If -debug-buffer-size=N is set N > 0,
dbgs() buffers its output until program termination and dumps the last N
characters sent to it. This is handy when debugging very large inputs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92002 91177308-0d34-0410-b5e6-96231b3b80d8
and outputs it when explicitly flushed. The intent is to use it in
situations such as debug output logging where a signal handler can take
care of flushing the buffer at program termination.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92001 91177308-0d34-0410-b5e6-96231b3b80d8
instead use the appropriate subreggy thing. This generates identical
code on some large apps (thanks to Evan's cross class coalescing
stuff he did back in july). This means that MOV16r0 can go away
completely in the future soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91972 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91943 91177308-0d34-0410-b5e6-96231b3b80d8
argument to runJITOnFunction(), which caused a null pointer dereference at
every call.
Patch by Gianluca Guida!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91939 91177308-0d34-0410-b5e6-96231b3b80d8
These checks would often trigger on unreachable statements inserted by
bugpoint, leading it astray.
It would be nice if we could distinguish unreachable blocks from errors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91923 91177308-0d34-0410-b5e6-96231b3b80d8
Made LEA memory operands emit only 4 MCInst operands.
Made the scale operand equal 1 for instructions that have no
SIB byte.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91919 91177308-0d34-0410-b5e6-96231b3b80d8
load is needed when we have a small store into a large alloca (at which
point we get a load/insert/store sequence), but when you do a full-sized
store, this load ends up being dead.
This dead load is bad in really large nasty testcases where the load ends
up causing mem2reg to insert large chains of dependent phi nodes which only
ADCE can delete. Instead of doing this, just don't insert the dead load.
This fixes rdar://6864035
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91917 91177308-0d34-0410-b5e6-96231b3b80d8
missing check that an array reference doesn't go past the end of the array,
and remove some redundant checks for in-bound array and vector references
that are no longer needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91897 91177308-0d34-0410-b5e6-96231b3b80d8
by merging all returns in a function into a single one, but simplifycfg
currently likes to duplicate the return (an unfortunate choice!)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91890 91177308-0d34-0410-b5e6-96231b3b80d8
instead of stored. This reduces memdep memory usage, and also eliminates a bunch of
weakvh's. This speeds up gvn on gcc.c-torture/20001226-1.c from 23.9s to 8.45s (2.8x)
on a different machine than earlier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91885 91177308-0d34-0410-b5e6-96231b3b80d8
return partial registers. This affected the back-end lowering code some.
Also patch up some places I missed before in the "get" functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91880 91177308-0d34-0410-b5e6-96231b3b80d8
