patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
multiple uses. In some cases, all the uses are the same operation,
so instcombine can go ahead and promote the phi. In the testcase
this pushes an add out of the loop.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123568 91177308-0d34-0410-b5e6-96231b3b80d8
over a phi node by applying it to each operand may be wrong if the
operation and the phi node are mutually interdependent (the testcase
has a simple example of this). So only do this transform if it would
be correct to perform the operation in each predecessor of the block
containing the phi, i.e. if the other operands all dominate the phi.
This should fix the FFMPEG snow.c regression reported by İsmail Dönmez.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119347 91177308-0d34-0410-b5e6-96231b3b80d8
when both the source and dest are illegal types, since it would cause
the phi to grow (for example, we shouldn't transform test14b's phi to
a phi on i320). This fixes an infinite loop on i686 bootstrap with
phi slicing turned on, so turn it back on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86483 91177308-0d34-0410-b5e6-96231b3b80d8
not turn a PHI in a legal type into a PHI of an illegal type, and
add a new optimization that breaks up insane integer PHI nodes into
small pieces (PR3451).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86443 91177308-0d34-0410-b5e6-96231b3b80d8
I don't know what Dan wants to do with phi-merge-gep.ll, I'll let
him deal with it because instcombine may end up sinking these.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85739 91177308-0d34-0410-b5e6-96231b3b80d8
not the max. This didn't matter until the previous patch because
instcombine would refuse to sink loads with differenting alignments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85738 91177308-0d34-0410-b5e6-96231b3b80d8
phis, it didn't preserve the alignment of the load. This is a missed
optimization of the alignment is high and a miscompilation when the
alignment is low.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85736 91177308-0d34-0410-b5e6-96231b3b80d8
Make use of the END. facility on all files > 1K so that we aren't wasting CPU
cycles searching for RUN: lines that we'll never find.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36059 91177308-0d34-0410-b5e6-96231b3b80d8
Note that this reduces code size anyway (as well as making further
optimizations simpler) so it's always a win.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17739 91177308-0d34-0410-b5e6-96231b3b80d8
