| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One performs: (X == 13 | X == 14) -> X-13 <u 2
The other: (A == C1 || A == C2) -> (A & ~(C1 ^ C2)) == C1
The problem is that there are certain values of C1 and C2 that
trigger both transforms but the first one blocks out the second,
this generates suboptimal code.
Reordering the transforms should be better in every case and
allows us to do interesting stuff like turn:
%shr = lshr i32 %X, 4
%and = and i32 %shr, 15
%add = add i32 %and, -14
%tobool = icmp ne i32 %add, 0
into:
%and = and i32 %X, 240
%tobool = icmp ne i32 %and, 224
llvm-svn: 179493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(or (bool?A:B),(bool?C:D)) --> (bool?(or A,C):(or B,D))
By the time the OR is visited, both the SELECTs have been visited and not
optimized and the OR itself hasn't been transformed so we do this transform in
the hopes that the new ORs will be optimized.
The transform is explicitly disabled for vector-selects until "codegen matures
to handle them better".
Patch by Muhammad Tauqir!
llvm-svn: 175380
|
|
|
|
| |
llvm-svn: 131604
|
|
|
|
|
|
|
| |
canonical, and generally leads to better code. Found while looking at
an article about saturating arithmetic.
llvm-svn: 129545
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(icmp ult (X + CA), C1 + 1) if C2 + CA == C1.
InstCombine creates these so now we compile x == 23 || x == 24 || x == 25 to
%x.off = add i32 %x, -23
%1 = icmp ult i32 %x.off, 3
instead of
%x.off = add i32 %x, -23
%1 = icmp ult i32 %x.off, 2
%cmp3 = icmp eq i32 %x, 25
%ret2 = or i1 %1, %cmp3
llvm-svn: 122248
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Reassociate does this but it doesn't catch all cases (e.g. if the operands are i1).
llvm-svn: 113651
|
|
|
|
| |
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: 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: 97799
|
|
|
|
|
|
|
| |
for vectors. Codegen is generating awful code or segfaulting
in various cases (e.g. PR6204).
llvm-svn: 95058
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
on the example in PR4216. This doesn't trigger in the testsuite,
so I'd really appreciate someone scrutinizing the logic for
correctness.
llvm-svn: 92458
|
|
|
|
|
|
| |
and.
llvm-svn: 92419
|
|
|
|
|
|
|
| |
handle them efficiently. This is the opposite direction of the transformation
we used to have here.
llvm-svn: 92418
|
|
|
|
|
|
|
|
|
|
|
| |
pointer to int casts that confuse later optimizations. See PR3351
for details.
This improves but doesn't complete fix 483.xalancbmk because llvm-gcc
does this xform in GCC's "fold" routine as well. Clang++ will do
better I guess.
llvm-svn: 92408
|
|
|
|
| |
llvm-svn: 90046
|
|
|
|
|
|
|
| |
All of the 'demorgan' related xforms need to use
dyn_castNotVal, not m_Not.
llvm-svn: 85119
|
|
|
|
| |
llvm-svn: 85090
|
|
|
|
|
|
| |
not (or (icmp, icmp)) -> and(icmp, icmp)
llvm-svn: 85085
|
|
|
|
| |
llvm-svn: 85083
|
|
|
|
|
|
|
|
| |
input filename so that opt doesn't print the input filename in the
output so that grep lines in the tests don't unintentionally match
strings in the input filename.
llvm-svn: 81537
|
|
|
|
| |
llvm-svn: 81257
|
|
|
|
|
|
| |
of using llvm-as, now that opt supports this.
llvm-svn: 81226
|
|
|
|
| |
llvm-svn: 47793
|
|
|
|
|
|
|
| |
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.
llvm-svn: 36059
|
|
|
|
|
|
| |
Upgrade tests to work with new llvm.exp version of llvm_runtest.
llvm-svn: 36013
|
|
llvm-svn: 33296
|