LiveVariables::HandlePhysRegDef private they use information that is
not in memory when LiveVariables finishes the analysis.
Also update the TwoAddressInstructionPass to not use this interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10755 91177308-0d34-0410-b5e6-96231b3b80d8
The first change (which is disabled) compactifies all of the function constant
pools into the global constant pool, in an attempt to reduce the amount of
duplication and overhead. Unfortunately, as the comment indicates, this is
not yet a win, so it is disabled.
The second change sorts the typeid's so that those types that can be used
by instructions in the program appear earlier in the table than those that
cannot (such as structures and arrays). This causes the instructions to
be able to use the dense encoding more often, saving about 5K on 254.gap.
This is only a .65% savings though, unfortunately. :(
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10754 91177308-0d34-0410-b5e6-96231b3b80d8
Fix iterator invalidation problems which was causing -mstrip to miss some
entries, and read free'd memory. This shrinks the symbol table of 254.gap
from 333 to 284 bytes! :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10751 91177308-0d34-0410-b5e6-96231b3b80d8
occurs when the symbol table for a module has been stripped, making all of the
function local symbols go away.
This saves 6728 bytes in the stripped bytecode file of 254.gap (which obviously
has 841 functions), which isn't a ton, but helps and was easy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10750 91177308-0d34-0410-b5e6-96231b3b80d8
* Refactor reader stuff out of include/llvm/Bytecode/Primitives.h. This is
internal implementation details for the reader, not public interfaces!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10739 91177308-0d34-0410-b5e6-96231b3b80d8
This should get hunked over to the Sparc backend, along with
MachineCodeForInstruction and a bunch of files in include/llvm/Codegen,
but those battles will have to wait for a later time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10731 91177308-0d34-0410-b5e6-96231b3b80d8
of the register allocator as follows:
before after
mesa 2.3790 1.5994
vpr 2.6008 1.2078
gcc 1.9840 0.5273
mcf 0.2569 0.0470
eon 1.8468 1.4359
twolf 0.9475 0.2004
burg 1.6807 1.3300
lambda 1.2191 0.3764
Speedups range anyware from 30% to over 400% :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10712 91177308-0d34-0410-b5e6-96231b3b80d8
A = B op C where A == C, but this cannot really occur in practice
because of SSA form. Add an assert to check that just to be safe.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10682 91177308-0d34-0410-b5e6-96231b3b80d8
return value from signal() (which should be the same type; it's just not
typedef'd).
This fixes the build on Solaris.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10675 91177308-0d34-0410-b5e6-96231b3b80d8
turn a memory address back into the LLVM global object that starts at that
address. Note that this won't cause any additional datastructures to be built
for clients of the EE that don't need this information.
Also modified some code to not access the GlobalAddress map directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10674 91177308-0d34-0410-b5e6-96231b3b80d8
