| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
I think this is the last of autoupgrade that can be removed in 3.1.
Can the atomic upgrade stuff also go?
llvm-svn: 145169
|
|
|
|
|
|
| |
for adding other tests.
llvm-svn: 145143
|
|
|
|
|
|
| |
resume. Note that some of these tests were basically dead.
llvm-svn: 140076
|
|
|
|
|
|
| |
exception.
llvm-svn: 139117
|
|
|
|
| |
llvm-svn: 139046
|
|
|
|
| |
llvm-svn: 138759
|
|
|
|
|
|
|
|
|
|
| |
or store to the address returned by the PHI node then we can consider this incoming value as dead and remove the edge pointing there, unless there are instructions that can affect control flow executed in between.
In theory this could be extended to other instructions, eg. division by zero, but it's likely that it will "miscompile" some code because people depend on div by zero not trapping. NULL pointer dereference usually leads to a crash so we should be on the safe side.
This shrinks the size of a Release clang by 16k on x86_64.
llvm-svn: 138618
|
|
|
|
|
|
|
|
| |
This commit includes a mention of the landingpad instruction, but it's not
changing the behavior around it. I think the current behavior is correct,
though. Bill, can you double-check that?
llvm-svn: 137691
|
|
|
|
|
|
|
|
|
|
| |
of the instruction.
Note that this change affects the existing non-atomic load and store
instructions; the parser now accepts both forms, and the change is noted
in the release notes.
llvm-svn: 137527
|
|
|
|
| |
llvm-svn: 134820
|
|
|
|
|
|
|
|
|
| |
nodes.
Original message:
Let simplify cfg simplify bb with only debug and lifetime intrinsics.
llvm-svn: 134182
|
|
|
|
|
|
| |
lifetime intrinsics" due to buildbot failures.
llvm-svn: 134071
|
|
|
|
| |
llvm-svn: 134057
|
|
|
|
|
|
|
|
|
|
|
| |
In cases such as the attached test, where the case value for a switch
destination is used in a phi node that follows the destination, it
might be better to replace that value with the condition value of the
switch, so that more blocks can be folded away with
TryToSimplifyUncondBranchFromEmptyBlock because there are less
conflicts in the phi node.
llvm-svn: 133344
|
|
|
|
|
|
| |
was replaced with return of a "first class aggregate".
llvm-svn: 133245
|
|
|
|
|
|
|
|
|
|
|
|
| |
then we don't want to set the destination in the indirect branch to the
destination. This is because the indirect branch needs its destinations to have
had their block addresses taken. This isn't so of the new critical edge that's
split during this process. If it turns out that the destination block has only
one predecessor, and that being a BB with an indirect branch, then it won't be
marked as 'used' and may be removed.
PR10072
llvm-svn: 132638
|
|
|
|
|
|
|
|
| |
to also clean up the condition of any conditional terminator it folds to be unconditional, if that turns the condition into dead code. This just means it calls RecursivelyDeleteTriviallyDeadInstructions() in strategic spots. It defaults to the old behavior.
I also changed -simplifycfg, -jump-threading and -codegenprepare to use this to produce slightly better code without any extra cleanup passes (AFAICT this was the only place in -simplifycfg where now-dead conditions of replaced terminators weren't being cleaned up). The only other user of this function is -sccp, but I didn't read that thoroughly enough to figure out whether it might be holding pointers to instructions that could be deleted by this.
llvm-svn: 131855
|
|
|
|
| |
llvm-svn: 131621
|
|
|
|
| |
llvm-svn: 131345
|
|
|
|
| |
llvm-svn: 130528
|
|
|
|
| |
llvm-svn: 130527
|
|
|
|
|
|
| |
phi node folding
llvm-svn: 130526
|
|
|
|
|
|
| |
Assign DebugLoc to this new trap instruction.
llvm-svn: 130315
|
|
|
|
|
|
|
| |
translation fails. We were bailing out in some cases that would
cause us to miss GVN'ing some non-local cases away.
llvm-svn: 130206
|
|
|
|
| |
llvm-svn: 129114
|
|
|
|
|
|
| |
match.
llvm-svn: 129078
|
|
|
|
|
|
| |
of pointers in an std::map.
llvm-svn: 127650
|
|
|
|
| |
llvm-svn: 127366
|
|
|
|
|
|
|
|
| |
reachable uses, but there still might be uses in dead blocks. Use the
standard solution of replacing all the uses with undef. This is
a rare case because it's very sensitive to phase ordering in SimplifyCFG.
llvm-svn: 127299
|
|
|
|
|
|
|
|
| |
branch.
Based on a patch by Alistair Lynn.
llvm-svn: 126647
|
|
|
|
|
|
|
| |
Yes, there are other types than i8* and GEPs on them can produce an add+multiply.
We don't consider that cheap enough to be speculatively executed.
llvm-svn: 126481
|
|
|
|
| |
llvm-svn: 126452
|
|
|
|
|
|
| |
unconditionally.
llvm-svn: 126445
|
|
|
|
|
|
|
|
| |
switch. If we used only one icmp, don't turn it into a switch.
Also prevent the switch-to-icmp transform from creating identity adds, noticed by Marius Wachtler.
llvm-svn: 125056
|
|
|
|
|
|
|
|
| |
are not sorted into sub+icmp.
This transforms another 1000 switches in gcc.c.
llvm-svn: 124826
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the job of the later optzn passes easier, allowing the vast amount of
icmp transforms to chew on it.
We transform 840 switches in gcc.c, leading to a 16k byte shrink of the resulting
binary on i386-linux.
The testcase from README.txt now compiles into
decl %edi
cmpl $3, %edi
sbbl %eax, %eax
andl $1, %eax
ret
llvm-svn: 124724
|
|
|
|
| |
llvm-svn: 124526
|
|
|
|
| |
llvm-svn: 124522
|
|
|
|
|
|
| |
unconditional predecessor to enable TCE on demand.
llvm-svn: 124518
|
|
|
|
| |
llvm-svn: 124478
|
|
|
|
|
|
|
|
| |
branches. PR8575, rdar://5134905, rdar://8911460.
- Allow codegen tail duplication to dup small return blocks after register
allocation is done.
llvm-svn: 124462
|
|
|
|
| |
llvm-svn: 122054
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
comparisons formed by comparisons. For example,
this:
void foo(unsigned x) {
if (x == 0 || x == 1 || x == 3 || x == 4 || x == 6)
bar();
}
compiles into:
_foo: ## @foo
## BB#0: ## %entry
cmpl $6, %edi
ja LBB0_2
## BB#1: ## %entry
movl %edi, %eax
movl $91, %ecx
btq %rax, %rcx
jb LBB0_3
instead of:
_foo: ## @foo
## BB#0: ## %entry
cmpl $2, %edi
jb LBB0_4
## BB#1: ## %switch.early.test
cmpl $6, %edi
ja LBB0_3
## BB#2: ## %switch.early.test
movl %edi, %eax
movl $88, %ecx
btq %rax, %rcx
jb LBB0_4
This catches a bunch of cases in GCC, which look like this:
%804 = load i32* @which_alternative, align 4, !tbaa !0
%805 = icmp ult i32 %804, 2
%806 = icmp eq i32 %804, 3
%or.cond121 = or i1 %805, %806
%807 = icmp eq i32 %804, 4
%or.cond124 = or i1 %or.cond121, %807
br i1 %or.cond124, label %.thread, label %808
turning this into a range comparison.
llvm-svn: 122045
|
|
|
|
|
|
|
|
|
|
| |
which is simpler than finding a place to insert in BB.
- Don't perform the 'if condition hoisting' xform on certain
i1 PHIs, as it interferes with switch formation.
This re-fixes "example 7", without breaking the world hopefully.
llvm-svn: 121764
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
first, it can kick in on blocks whose conditions have been
folded to a constant, even though one of the edges will be
trivially folded.
second, it doesn't clean up the "if diamond" that it just
eliminated away. This is a problem because other simplifycfg
xforms kick in depending on the order of block visitation,
causing pointless work.
llvm-svn: 121762
|
|
|
|
| |
llvm-svn: 121750
|
|
|
|
|
|
| |
work, but fixes 400.perlbmk.
llvm-svn: 121749
|
|
|
|
|
|
|
|
| |
r121694, the most recent state
where I'm confident there were no crashes or miscompilations. XFAIL the test added since then for now.
llvm-svn: 121733
|
|
|
|
|
|
| |
invalidation issue, causing a crash on some versions of perlbmk.
llvm-svn: 121728
|
|
|
|
|
|
| |
Fixes PR 8780.
llvm-svn: 121705
|