| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 120051
|
| |
|
|
|
|
|
|
|
|
|
|
| |
fairly systematic way in instcombine. Some of these cases were already dealt
with, in which case I removed the existing code. The case of Add has a bunch of
funky logic which covers some of this plus a few variants (considers shifts to be
a form of multiplication), which I didn't touch. The simplification performed is:
A*B+A*C -> A*(B+C). The improvement is to do this in cases that were not already
handled [such as A*B-A*C -> A*(B-C), which was reported on the mailing list], and
also to do it more often by not checking for "only one use" if "B+C" simplifies.
llvm-svn: 120024
|
| |
|
|
|
|
|
|
| |
instructions out of InstCombine and into InstructionSimplify. While
there, introduce an m_AllOnes pattern to simplify matching with integers
and vectors with all bits equal to one.
llvm-svn: 119536
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SimplifyAssociativeOrCommutative) "(A op C1) op C2" -> "A op (C1 op C2)",
which previously was only done if C1 and C2 were constants, to occur whenever
"C1 op C2" simplifies (a la InstructionSimplify). Since the simplifying operand
combination can no longer be assumed to be the right-hand terms, consider all of
the possible permutations. When compiling "gcc as one big file", transform 2
(i.e. using right-hand operands) fires about 4000 times but it has to be said
that most of the time the simplifying operands are both constants. Transforms
3, 4 and 5 each fired once. Transform 6, which is an existing transform that
I didn't change, never fired. With this change, the testcase is now optimized
perfectly with one run of instcombine (previously it required instcombine +
reassociate + instcombine, and it may just have been luck that this worked).
llvm-svn: 119002
|
| |
|
|
|
|
|
|
|
| |
instcombine transforms
to expose greater opportunities for store narrowing in codegen. This patch fixes a potential
infinite loop in instcombine caused by one of the introduced transforms being overly aggressive.
llvm-svn: 113763
|
| |
|
|
|
|
| |
on to Owen.
llvm-svn: 113720
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the and's mask.
This can result in increased opportunities for store narrowing in code generation. Update a number of
tests for this change. This fixes <rdar://problem/8285027>.
Additionally, because this inverts the order of ors and ands, some patterns for optimizing or-of-and-of-or
no longer fire in instances where they did originally. Add a simple transform which recaptures most of these
opportunities: if we have an or-of-constant-or and have failed to fold away the inner or, commute the order
of the two ors, to give the non-constant or a chance for simplification instead.
llvm-svn: 113679
|
| |
|
|
| |
llvm-svn: 113608
|
| |
|
|
|
|
| |
single test. Patch by Dirk Steinke!
llvm-svn: 113423
|
| |
|
|
| |
llvm-svn: 110036
|
| |
|
|
|
|
|
| |
like my instcombine patch.", in an attempt to fix Clang i386 bootstrap.
- Also PR7719.
llvm-svn: 109953
|
| |
|
|
| |
llvm-svn: 108614
|
| |
|
|
|
|
| |
Working on testcases for Owen.
llvm-svn: 108494
|
| |
|
|
| |
llvm-svn: 108436
|
| |
|
|
|
|
|
|
| |
the corresponding or-icmp-and pattern. This has the added benefit of doing
the matching earlier, and thus being less susceptible to being confused by
earlier transforms.
llvm-svn: 108429
|
| |
|
|
|
|
| |
This now passes LIT, nighty test, and llvm-gcc bootstrap on my machine.
llvm-svn: 108422
|
| |
|
|
| |
llvm-svn: 108389
|
| |
|
|
|
|
| |
value into a single larger comparison.
llvm-svn: 108378
|
| |
|
|
| |
llvm-svn: 108322
|
| |
|
|
|
|
| |
can't repro any problems with a manual self-host.
llvm-svn: 108320
|
| |
|
|
| |
llvm-svn: 108153
|
| |
|
|
| |
llvm-svn: 108152
|
| |
|
|
| |
llvm-svn: 108148
|
| |
|
|
| |
llvm-svn: 108141
|
| |
|
|
| |
llvm-svn: 108140
|
| |
|
|
| |
llvm-svn: 108139
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
x) ^ z which is one instruction shorter. (PR6773)
before:
%and = and i32 %y, %x
%neg = xor i32 %x, -1
%and4 = and i32 %z, %neg
%xor = xor i32 %and4, %and
after:
%xor1 = xor i32 %z, %y
%and2 = and i32 %xor1, %x
%xor = xor i32 %and2, %z
llvm-svn: 108136
|
| |
|
|
| |
llvm-svn: 100859
|
| |
|
|
|
|
|
|
|
|
|
| |
parts of the cmp|cmp and cmp&cmp folding logic wasn't prepared for vectors
(unrelated to the bug but noticed while in the code) and the code was
*definitely* not safe to use by the (cast icmp)|(cast icmp) handling logic
that I added in r95855. Fix all this up by changing the various routines
to more consistently use IRBuilder and not pass in the I which had the wrong
type.
llvm-svn: 97801
|
| |
|
|
|
|
| |
compares, noticed by inspection.
llvm-svn: 97795
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
long test(long x) { return (x & 123124) | 3; }
Currently compiles to:
_test:
orl $3, %edi
movq %rdi, %rax
andq $123127, %rax
ret
This is because instruction and DAG combiners canonicalize
(or (and x, C), D) -> (and (or, D), (C | D))
However, this is only profitable if (C & D) != 0. It gets in the way of the
3-addressification because the input bits are known to be zero.
llvm-svn: 97616
|
| |
|
|
|
|
|
| |
and T->isPointerTy(). Convert most instances of the first form to the second form.
Requested by Chris.
llvm-svn: 96344
|
| |
|
|
|
|
| |
isInteger, we now have isFloatTy and isIntegerTy. Requested by Chris!
llvm-svn: 96223
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
what it does. Enhance it to return false to optimizing vector
sign extensions from vector comparisions, which is the idiom used
to get a splatted vector for a vector comparison.
Doing this breaks vector-casts.ll, add some compensating
transformations to handle the important case they cover without
depending on this canonicalization.
This fixes rdar://7434900 a serious pessimization of vector compares.
llvm-svn: 95855
|
| |
|
|
| |
llvm-svn: 95781
|
| |
|
|
| |
llvm-svn: 95643
|
| |
|
|
|
|
| |
xform.
llvm-svn: 95642
|
| |
|
|
|
|
|
|
|
| |
xform it is checking to actually pass. There is no need to match
m_SelectCst<0, -1> since instcombine canonicalizes that into not(sext).
Add matches for sext(not(x)) in addition to not(sext(x)).
llvm-svn: 95420
|
| |
|
|
|
|
|
| |
for vectors. Codegen is generating awful code or segfaulting
in various cases (e.g. PR6204).
llvm-svn: 95058
|
| |
|
|
|
|
|
|
| |
"sext cond" instead of a select. This simplifies some instcombine
code, matches the policy for zext (cond ? 1 : 0 -> zext), and allows
us to generate better code for a testcase on ppc.
llvm-svn: 94339
|
| |
|
|
|
|
| |
Evans!
llvm-svn: 93884
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
good code on PR4216:
_test_bitfield: ## @test_bitfield
orl $32962, %edi
movl $4294941946, %eax
andq %rdi, %rax
ret
instead of:
_test_bitfield:
movl $4294941696, %ecx
movl %edi, %eax
orl $194, %edi
orl $32768, %eax
andq $250, %rdi
andq %rax, %rcx
movq %rdi, %rax
orq %rcx, %rax
ret
Evan is looking into the remaining andq+imm -> andl optimization.
llvm-svn: 93147
|
|
|
it does make sense to keep them together, at least for now.
llvm-svn: 92711
|