| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
| 
| 
|  | 
to use it.
llvm-svn: 123501
 | 
| | 
| 
| 
| 
| 
| 
|  | 
"promote a bunch of load and stores" logic, allowing the code to
be shared and reused.
llvm-svn: 123456
 | 
| | 
| 
| 
|  | 
llvm-svn: 123426
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
DT->changeImmediateDominator() trivially ignores identity updates, so there is
really no need for the uniqueing provided by SmallPtrSet.
I expect this to fix PR8954.
llvm-svn: 123286
 | 
| | 
| 
| 
|  | 
llvm-svn: 123247
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
a new helper function so it can be reused in e.g. an upcoming SimplifySwitchOnSelect.
No functional change.
llvm-svn: 123234
 | 
| | 
| 
| 
| 
| 
|  | 
is floating around in the ether.
llvm-svn: 123223
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
phi nodes.  It is called from MergeBlockIntoPredecessor which is 
called from GVN, which claims to preserve these.
I'm skeptical that this is the actual problem behind PR8954, but
this is a stab in the right direction.
llvm-svn: 123222
 | 
| | 
| 
| 
|  | 
llvm-svn: 123221
 | 
| | 
| 
| 
| 
| 
|  | 
loop info.
llvm-svn: 123074
 | 
| | 
| 
| 
|  | 
llvm-svn: 123071
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
they all ready do). This removes two dominator recomputations prior to isel,
which is a 1% improvement in total llc time for 403.gcc.
The only potentially suspect thing is making GCStrategy recompute dominators if
it used a custom lowering strategy.
llvm-svn: 123064
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
1. Take a flags argument instead of a bool.  This makes
   it more clear to the reader what it is used for.
2. Add a flag that says that "remapping a value not in the
   map is ok".
3. Reimplement MapValue to share a bunch of code and be a lot
   more efficient.  For lookup failures, don't drop null values
   into the map.
4. Using the new flag a bunch of code can vaporize in LinkModules
   and LoopUnswitch, kill it.
No functionality change.
llvm-svn: 123058
 | 
| | 
| 
| 
|  | 
llvm-svn: 123025
 | 
| | 
| 
| 
| 
| 
| 
|  | 
InstructionSimplify on instructions that didn't change since the
last time round the loop.
llvm-svn: 122745
 | 
| | 
| 
| 
| 
| 
|  | 
so that Dominators.h is *just* domtree.  Also prune #includes a bit.
llvm-svn: 122714
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
described
in the PR, the pass could break LCSSA form when inserting preheaders.  It probably
would be easy enough to fix this, but since currently we always go into LCSSA form
after running this pass, doing so is not urgent.
llvm-svn: 122695
 | 
| | 
| 
| 
| 
| 
|  | 
operands are visited before the instructions themselves.
llvm-svn: 122647
 | 
| | 
| 
| 
|  | 
llvm-svn: 122645
 | 
| | 
| 
| 
|  | 
llvm-svn: 122642
 | 
| | 
| 
| 
| 
| 
|  | 
and superseded by IRBuilder.
llvm-svn: 122576
 | 
| | 
| 
| 
|  | 
llvm-svn: 122556
 | 
| | 
| 
| 
| 
| 
| 
|  | 
getOrEnforceKnownAlignment function, which simplifies the code
and makes it stronger.
llvm-svn: 122555
 | 
| | 
| 
| 
|  | 
llvm-svn: 122554
 | 
| | 
| 
| 
| 
| 
| 
|  | 
new gcc warning that complains on self-assignments and
self-initializations.
llvm-svn: 122458
 | 
| | 
| 
| 
| 
| 
| 
|  | 
visit instructions before their uses, since InstructionSimplify does a
better job in that case.  All this prompted by Frits van Bommel.
llvm-svn: 122343
 | 
| | 
| 
| 
| 
| 
| 
|  | 
not very important since the pass is only used for testing, but it does make
it more realistic.  Suggested by Frits van Bommel.
llvm-svn: 122336
 | 
| | 
| 
| 
|  | 
llvm-svn: 122265
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
it could only be tested indirectly, via instcombine, gvn or some other
pass that makes use of InstructionSimplify, which means that testcases
had to be carefully contrived to dance around any other transformations
that that pass did.
llvm-svn: 122264
 | 
| | 
| 
| 
| 
| 
|  | 
to make sure that the reused alloca has sufficient alignment.
llvm-svn: 122236
 | 
| | 
| 
| 
|  | 
llvm-svn: 122235
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
argument.  The generated alloca has to have at least the alignment of the
byval, if not, the client may be making assumptions that the new alloca won't
satisfy.
llvm-svn: 122234
 | 
| | 
| 
| 
|  | 
llvm-svn: 122156
 | 
| | 
| 
| 
|  | 
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
 | 
| | 
| 
| 
|  | 
llvm-svn: 121838
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
|  | 
breaking the selfhost builds, though I can't fathom how.
llvm-svn: 121761
 | 
| | 
| 
| 
| 
| 
|  | 
when all 2-entry phis are simplified away.
llvm-svn: 121760
 | 
| | 
| 
| 
| 
| 
|  | 
don't print it unless the xform happens.
llvm-svn: 121758
 | 
| | 
| 
| 
|  | 
llvm-svn: 121757
 | 
| | 
| 
| 
|  | 
llvm-svn: 121756
 | 
| | 
| 
| 
|  | 
llvm-svn: 121755
 | 
| | 
| 
| 
| 
| 
| 
|  | 
GetIfCondition faster by avoiding pred_iterator.  No
really interesting change.
llvm-svn: 121754
 | 
| | 
| 
| 
|  | 
llvm-svn: 121753
 | 
| | 
| 
| 
| 
| 
|  | 
code a bit, switch from constant folding to instsimplify.
llvm-svn: 121751
 | 
| | 
| 
| 
| 
| 
|  | 
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
 |