| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
when changing the stride of a comparison so that it's slightly
more precise, by having it scan the instruction list to determine
if there is a use of the condition after the point where the
condition will be inserted.
llvm-svn: 52371
|
| |
|
|
|
|
| |
across runs.
llvm-svn: 52361
|
| |
|
|
| |
llvm-svn: 52339
|
| |
|
|
|
|
| |
friends.
llvm-svn: 52318
|
| |
|
|
| |
llvm-svn: 52316
|
| |
|
|
|
|
|
|
|
|
| |
I'm at it, rename it to FindInsertedValue.
The only functional change is that newly created instructions are no longer
added to instcombine's worklist, but that is not really necessary anyway (and
I'll commit some improvements next that will completely remove the need).
llvm-svn: 52315
|
| |
|
|
| |
llvm-svn: 52295
|
| |
|
|
|
|
| |
change.
llvm-svn: 52267
|
| |
|
|
|
|
| |
when trying to sink stores.
llvm-svn: 52259
|
| |
|
|
|
|
| |
for it to generate use-before-def IR, such as in this testcase.
llvm-svn: 52258
|
| |
|
|
|
|
|
| |
structure checks are incorrect if the blocks aren't distinct.
Fixes PR2435.
llvm-svn: 52257
|
| |
|
|
| |
llvm-svn: 52251
|
| |
|
|
| |
llvm-svn: 52247
|
| |
|
|
| |
llvm-svn: 52246
|
| |
|
|
|
|
| |
predecessor BB if any of its operands are defined but not used in BB. The transformation will prevent the operand from being sunk into the use block.
llvm-svn: 52244
|
| |
|
|
| |
llvm-svn: 52243
|
| |
|
|
| |
llvm-svn: 52242
|
| |
|
|
| |
llvm-svn: 52226
|
| |
|
|
|
|
|
|
| |
execute integer arithmetic instructions. FP selects are more likely to be expensive (even compared to branch on fcmp). This is not a wonderful solution but I rather err on the side of conservative.
This fixes the heapsort performance regressions.
llvm-svn: 52224
|
| |
|
|
|
|
|
|
| |
like general badness to me, likely to cause code explosion).
Patch by Florian Brandner.
llvm-svn: 52223
|
| |
|
|
|
|
|
|
| |
useless insert-extract chains, similar to how it folds them for vectors.
Add a testcase for this.
llvm-svn: 52217
|
| |
|
|
| |
llvm-svn: 52212
|
| |
|
|
| |
llvm-svn: 52191
|
| |
|
|
| |
llvm-svn: 52138
|
| |
|
|
|
|
| |
result of a weak function.
llvm-svn: 52137
|
| |
|
|
|
|
|
|
|
|
|
| |
of apint codegen failure is the DAG combiner doing
the wrong thing because it was comparing MVT's using
< rather than comparing the number of bits. Removing
the < method makes this mistake impossible to commit.
Instead, add helper methods for comparing bits and use
them.
llvm-svn: 52098
|
| |
|
|
|
|
| |
don't make i1 phis when it won't be possible to eliminate them.
llvm-svn: 52097
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
triangle shape and it contains a single, side effect free, cheap instruction. The branch is eliminated by adding a select instruction. i.e.
Turn
BB:
%t1 = icmp
br i1 %t1, label %BB1, label %BB2
BB1:
%t3 = add %t2, c
br label BB2
BB2:
=>
BB:
%t1 = icmp
%t4 = add %t2, c
%t3 = select i1 %t1, %t2, %t3
llvm-svn: 52073
|
| |
|
|
| |
llvm-svn: 52053
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and better control the abstraction. Rename the type
to MVT. To update out-of-tree patches, the main
thing to do is to rename MVT::ValueType to MVT, and
rewrite expressions like MVT::getSizeInBits(VT) in
the form VT.getSizeInBits(). Use VT.getSimpleVT()
to extract a MVT::SimpleValueType for use in switch
statements (you will get an assert failure if VT is
an extended value type - these shouldn't exist after
type legalization).
This results in a small speedup of codegen and no
new testsuite failures (x86-64 linux).
llvm-svn: 52044
|
| |
|
|
|
|
| |
otherwise, opt might crash.
llvm-svn: 52041
|
| |
|
|
|
|
|
|
| |
crash the opt. Just fix this.
Test case in llvm/test/Transforms/InstCombine/2008-06-05-ashr-crash.ll
llvm-svn: 52003
|
| |
|
|
|
|
|
|
|
|
| |
work and how to replace them into individual values. Also, when trying to
replace an aggregrate that is used by load or store with a single (large)
integer, don't crash (but don't replace the aggregrate either).
Also adds a testcase for both structs and arrays.
llvm-svn: 51997
|
| |
|
|
|
|
| |
not other instructions. This fixes a crash with the added testcase.
llvm-svn: 51992
|
| |
|
|
|
|
| |
passing its pointer. Fixes test with added testcase.
llvm-svn: 51991
|
| |
|
|
|
|
|
| |
function is passed as an argument instead of called. Also do this check a bit
earlier.
llvm-svn: 51990
|
| |
|
|
|
|
| |
deprecated by the GVN and GVNPRE passes.
llvm-svn: 51983
|
| |
|
|
| |
llvm-svn: 51955
|
| |
|
|
|
|
| |
changes).
llvm-svn: 51947
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
are the same as in unpacked structs, only field
positions differ. This only matters for structs
containing x86 long double or an apint; it may
cause backwards compatibility problems if someone
has bitcode containing a packed struct with a
field of one of those types.
The issue is that only 10 bytes are needed to
hold an x86 long double: the store size is 10
bytes, but the ABI size is 12 or 16 bytes (linux/
darwin) which comes from rounding the store size
up by the alignment. Because it seemed silly not
to pack an x86 long double into 10 bytes in a
packed struct, this is what was done. I now
think this was a mistake. Reserving the ABI size
for an x86 long double field even in a packed
struct makes things more uniform: the ABI size is
now always used when reserving space for a type.
This means that developers are less likely to
make mistakes. It also makes life easier for the
CBE which otherwise could not represent all LLVM
packed structs (PR2402).
Front-end people might need to adjust the way
they create LLVM structs - see following change
to llvm-gcc.
llvm-svn: 51928
|
| |
|
|
|
|
|
|
| |
domfrontier.
Don't crash when we encounter one of these.
llvm-svn: 51915
|
| |
|
|
| |
llvm-svn: 51890
|
| |
|
|
| |
llvm-svn: 51887
|
| |
|
|
| |
llvm-svn: 51864
|
| |
|
|
|
|
|
| |
out of instcombine into a new file in libanalysis. This also teaches
ComputeNumSignBits about the number of sign bits in a constantint.
llvm-svn: 51863
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
like:
char a[200];
init(a, a+200);
OR
int a[200];
char* b = (char*)a;
char* c = (char*)a;
foo(b, c);
llvm-svn: 51850
|
| |
|
|
| |
llvm-svn: 51848
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the conditions for performing the transform when only the
function declaration is available: no longer allow turning
i32 into i64 for example. Only allow changing between
pointer types, and between pointer types and integers of
the same size. For return values ptr -> intptr was already
allowed; I added ptr -> ptr and intptr -> ptr while there.
As shown by a recent objc testcase, changing the way
parameters/return values are passed can be fatal when calling
code written in assembler that directly manipulates call
arguments and return values unless the transform has no
impact on the way they are passed at the codegen level.
While it is possible to imagine an ABI that treats integers
of pointer size differently to pointers, I don't think LLVM
supports any so the transform should now be safe while still
being useful.
llvm-svn: 51834
|
| |
|
|
| |
llvm-svn: 51819
|
| |
|
|
| |
llvm-svn: 51817
|