| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 122678
|
|
|
|
|
|
|
|
|
|
|
| |
maintains the guarantee that the DenseSet expects two elements it contains to
not go from inequal to equal under its nose.
As a side-effect, this also lets us switch from iterating to a fixed-point to
actually maintaining a work queue of functions to look at again, and we don't
add thunks to our work queue so we don't need to detect and ignore them.
llvm-svn: 122677
|
|
|
|
|
|
| |
loop idiom pass exposed.
llvm-svn: 122674
|
|
|
|
|
|
| |
new testcase.
llvm-svn: 122662
|
|
|
|
|
|
|
| |
aggressively. In practice, this doesn't help anything though,
see the todo.
llvm-svn: 122660
|
|
|
|
|
|
| |
should be correct now.
llvm-svn: 122659
|
|
|
|
|
|
| |
operands are visited before the instructions themselves.
llvm-svn: 122647
|
|
|
|
| |
llvm-svn: 122645
|
|
|
|
| |
llvm-svn: 122642
|
|
|
|
|
|
|
| |
check for "multiple of a byte" in size to make it clear that the
>> 3 below is safe.
llvm-svn: 122604
|
|
|
|
| |
llvm-svn: 122593
|
|
|
|
| |
llvm-svn: 122585
|
|
|
|
|
|
| |
and superseded by IRBuilder.
llvm-svn: 122576
|
|
|
|
| |
llvm-svn: 122575
|
|
|
|
| |
llvm-svn: 122574
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
memsets. This is still missing one important validity check, but this is enough
to compile stuff like this:
void test0(std::vector<char> &X) {
for (std::vector<char>::iterator I = X.begin(), E = X.end(); I != E; ++I)
*I = 0;
}
void test1(std::vector<int> &X) {
for (long i = 0, e = X.size(); i != e; ++i)
X[i] = 0x01010101;
}
With:
$ clang t.cpp -S -o - -O2 -emit-llvm | opt -loop-idiom | opt -O3 | llc
to:
__Z5test0RSt6vectorIcSaIcEE: ## @_Z5test0RSt6vectorIcSaIcEE
## BB#0: ## %entry
subq $8, %rsp
movq (%rdi), %rax
movq 8(%rdi), %rsi
cmpq %rsi, %rax
je LBB0_2
## BB#1: ## %bb.nph
subq %rax, %rsi
movq %rax, %rdi
callq ___bzero
LBB0_2: ## %for.end
addq $8, %rsp
ret
...
__Z5test1RSt6vectorIiSaIiEE: ## @_Z5test1RSt6vectorIiSaIiEE
## BB#0: ## %entry
subq $8, %rsp
movq (%rdi), %rax
movq 8(%rdi), %rdx
subq %rax, %rdx
cmpq $4, %rdx
jb LBB1_2
## BB#1: ## %for.body.preheader
andq $-4, %rdx
movl $1, %esi
movq %rax, %rdi
callq _memset
LBB1_2: ## %for.end
addq $8, %rsp
ret
llvm-svn: 122573
|
|
|
|
| |
llvm-svn: 122572
|
|
|
|
| |
llvm-svn: 122567
|
|
|
|
| |
llvm-svn: 122565
|
|
|
|
| |
llvm-svn: 122563
|
|
|
|
|
|
| |
No functionality yet.
llvm-svn: 122562
|
|
|
|
| |
llvm-svn: 122561
|
|
|
|
| |
llvm-svn: 122556
|
|
|
|
|
|
|
| |
getOrEnforceKnownAlignment function, which simplifies the code
and makes it stronger.
llvm-svn: 122555
|
|
|
|
| |
llvm-svn: 122554
|
|
|
|
|
|
| |
variables in isBytewiseValue is not safe.
llvm-svn: 122550
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to compile "int cst[] = {-1, -1, -1};" into
movl $-1, 16(%rsp)
movq $-1, 8(%rsp)
instead of
movl _cst+8(%rip), %eax
movl %eax, 16(%rsp)
movq _cst(%rip), %rax
movq %rax, 8(%rsp)
llvm-svn: 122548
|
|
|
|
|
|
|
|
| |
verify are zero
are not the low bits of x, but the bits that WILL be the low bits after the operation completes.
llvm-svn: 122529
|
|
|
|
|
|
|
|
|
|
| |
late in the optimization
pipeline to be caught by instcombine, and it's not feasible to catch them in SimplifyCFG because the
use-lists are in an inconsistent state at the point where it could know that it need to simplify them.
Instead, have CodeGenPrepare look for trivially redundant PHIs as part of its general cleanup effort.
llvm-svn: 122516
|
|
|
|
|
|
| |
ConvertToScalarInfo
llvm-svn: 122462
|
|
|
|
|
|
|
| |
new gcc warning that complains on self-assignments and
self-initializations.
llvm-svn: 122458
|
|
|
|
|
|
| |
sext from i1.
llvm-svn: 122453
|
|
|
|
|
|
|
|
| |
if both A op B and A op C simplify. This fires fairly often but doesn't
make that much difference. On gcc-as-one-file it removes two "and"s and
turns one branch into a select.
llvm-svn: 122399
|
|
|
|
|
|
| |
instcombine is compared to instsimplify.
llvm-svn: 122397
|
|
|
|
|
|
|
|
|
| |
conditional branch values.
I still think that LVI should be handling this, but that capability is some ways off in the future,
and this matters for some significant benchmarks.
llvm-svn: 122378
|
|
|
|
| |
llvm-svn: 122371
|
|
|
|
|
|
| |
while at it.
llvm-svn: 122362
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
plenty left though!), in particular for multiplication.
llvm-svn: 122330
|
|
|
|
| |
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
|
|
|
|
|
|
| |
situation.
llvm-svn: 122258
|
|
|
|
| |
llvm-svn: 122249
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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
|
|
|
|
| |
llvm-svn: 122238
|
|
|
|
| |
llvm-svn: 122237
|
|
|
|
|
|
| |
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
|