Based on the ilist changes avoid allocating an entire Use object for the
end of the Use chain. This saves 8 bytes of memory for each Value allocated
in the program. For 176.gcc, this reduces us from 69.5M -> 66.0M, a 5.3%
memory savings.
llvm-svn: 19925
cases it represented them as 'unsigned's, which are not enough for 64-bit
hosts. In other cases, it represented them as uint64_t's, which are
inefficient for 32-bit hosts.
This patch unifies all of the sizes to use size_t instead.
llvm-svn: 19918
This file was schizophrenic when it came to representing sizes. In some
cases it represented them as 'unsigneds', which are not enough for 64-bit
hosts. In other cases, it represented them as uint64_t's, which are
inefficient for 32-bit hosts.
This patch unifies all of the sizes to use size_t instead.
llvm-svn: 19917
not invalidated on entry and on exit of the block. This fixes some N^2
behavior in common cases, and speeds up gcc another 5% to 22.35s.
llvm-svn: 19910
will cause us to miss cases where the input pointer to a load could be value
numbered to another load. Something like this:
%X = load int* %P1
%Y = load int* %P2
Those are obviously the same if P1/P2 are the same. The code this patch
removes attempts to handle that. However, since GCSE iterates, this doesn't
actually buy us anything: GCSE will first replace P1 or P2 with the other
one, then the load can be value numbered as equal.
Removing this code speeds up gcse a lot. On 176.gcc in debug mode, this
speeds up gcse from 29.08s -> 25.73s, a 13% savings.
llvm-svn: 19906
Adjust to changes in the User class, operand handling is very different.
PHI node and switch statements must handle explicit resizing of operand
lists.
llvm-svn: 19891
and num operands in the User class. this allows us to embed the operands
directly in the subclasses if possible. For example, for binary operators
we store the two operands in the derived class.
The has several effects:
1. it improves locality because the operands and instruction are together
2. it makes accesses to operands faster (one less load) if you access them
through the derived class pointer. For example this:
Value *GetBinaryOperatorOp(BinaryOperator *I, int i) {
return I->getOperand(i);
}
Was compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 4(%esp), %edx
movl 8(%esp), %eax
sall $4, %eax
movl 24(%edx), %ecx
addl %ecx, %eax
movl (%eax), %eax
ret
and is now compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 8(%esp), %eax
movl 4(%esp), %edx
sall $4, %eax
addl %edx, %eax
movl 44(%eax), %eax
ret
Accesses through "Instruction*" are unmodified.
3. This reduces memory consumption (by about 3%) by eliminating 1 word of
vector overhead and a malloc header on a seperate object.
4. This speeds up gccas about 10% (both debug and release builds) on
large things (such as 176.gcc). For example, it takes a debug build
from 172.9 -> 155.6s and a release gccas from 67.7 -> 61.8s
llvm-svn: 19883
