| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
For the time being this includes only some dummy test cases. Once the
generic implementation of the intrinsics cost function does something other
than assuming scalarization in all cases, or some target specializes the
interface, some real test cases can be added.
Also, for consistency, I changed the type of IID from unsigned to Intrinsic::ID
in a few other places.
llvm-svn: 171079
|
| |
|
|
| |
llvm-svn: 171076
|
| |
|
|
| |
llvm-svn: 171075
|
| |
|
|
|
|
|
| |
VectorType::getInteger() can not be used with them, because pointer size
depends on the target.
llvm-svn: 171070
|
| |
|
|
| |
llvm-svn: 171069
|
| |
|
|
|
|
| |
consistency
llvm-svn: 171061
|
| |
|
|
| |
llvm-svn: 171060
|
| |
|
|
|
|
|
|
|
| |
When the backend is used from clang, it should produce proper diagnostics
instead of just printing messages to errs(). Other clients may also want to
register their own error handlers with the LLVMContext, and the same handler
should work for warnings in the same way as the existing emitError methods.
llvm-svn: 171041
|
| |
|
|
|
|
|
|
| |
the StoreInst operands.
PR14705.
llvm-svn: 171023
|
| |
|
|
| |
llvm-svn: 171021
|
| |
|
|
|
|
|
|
| |
The bug was in the code that detects PHIs in if-then-else block sequence.
PR14701.
llvm-svn: 171008
|
| |
|
|
| |
llvm-svn: 171001
|
| |
|
|
|
|
|
|
| |
insert/extract costs.
Fixes an assert during the build of oggenc in the test suite.
llvm-svn: 171000
|
| |
|
|
|
|
| |
them more expensive.
llvm-svn: 170995
|
| |
|
|
| |
llvm-svn: 170990
|
| |
|
|
|
|
| |
attribute instead of the value of the attribute.
llvm-svn: 170972
|
| |
|
|
| |
llvm-svn: 170902
|
| |
|
|
| |
llvm-svn: 170883
|
| |
|
|
| |
llvm-svn: 170841
|
| |
|
|
| |
llvm-svn: 170831
|
| |
|
|
|
|
|
| |
and not the return type, which is void. A number of test
cases fail after adding the assertion in TTImpl.
llvm-svn: 170828
|
| |
|
|
|
|
|
|
|
|
| |
memory bound checks. Before the fix we were able to vectorize this loop from
the Livermore Loops benchmark:
for ( k=1 ; k<n ; k++ )
x[k] = x[k-1] + y[k];
llvm-svn: 170811
|
| |
|
|
|
|
|
|
|
|
| |
Before if-conversion we could check if a value is loop invariant
if it was declared inside the basic block. Now that loops have
multiple blocks this check is incorrect.
This fixes External/SPEC/CINT95/099_go/099_go
llvm-svn: 170756
|
| |
|
|
| |
llvm-svn: 170708
|
| |
|
|
|
|
|
|
| |
call, the call cannot be duplicated - Jump threading, loop unrolling, loop unswitching, and loop rotation are inhibited if they would duplicate the call.
Similarly inlining of the function is inhibited, if that would duplicate the call (in particular inlining is still allowed when there is only one callsite and the function has internal linkage).
llvm-svn: 170704
|
| |
|
|
|
|
| |
functional change.
llvm-svn: 170676
|
| |
|
|
| |
llvm-svn: 170675
|
| |
|
|
| |
llvm-svn: 170632
|
| |
|
|
| |
llvm-svn: 170626
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When the least bit of C is greater than V, (x&C) must be greater than V
if it is not zero, so the comparison can be simplified.
Although this was suggested in Target/X86/README.txt, it benefits any
architecture with a directly testable form of AND.
Patch by Kevin Schoedel
llvm-svn: 170576
|
| |
|
|
| |
llvm-svn: 170544
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This changes adds shadow and origin propagation for unknown intrinsics
by examining the arguments and ModRef behaviour. For now, only 3 classes
of intrinsics are handled:
- those that look like simple SIMD store
- those that look like simple SIMD load
- those that don't have memory effects and look like arithmetic/logic/whatever
operation on simple types.
llvm-svn: 170530
|
| |
|
|
|
|
|
|
|
|
| |
values.
MapVector is a bit heavyweight, but I don't see a simpler way. Also the
InductionList is unlikely to be large. This should help 3-stage selfhost
compares (PR14647).
llvm-svn: 170528
|
| |
|
|
|
|
| |
some minor comment reformatting.
llvm-svn: 170516
|
| |
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170502
|
| |
|
|
|
|
| |
alignment.
llvm-svn: 170486
|
| |
|
|
|
|
| |
InstCombine for unsafe floating-point add/sub.
llvm-svn: 170471
|
| |
|
|
|
|
| |
can disable it in clang.
llvm-svn: 170470
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of scalar operations.
For example on x86 with SSE4.2 a <8 x i8> add reduction becomes
movdqa %xmm0, %xmm1
movhlps %xmm1, %xmm1 ## xmm1 = xmm1[1,1]
paddw %xmm0, %xmm1
pshufd $1, %xmm1, %xmm0 ## xmm0 = xmm1[1,0,0,0]
paddw %xmm1, %xmm0
phaddw %xmm0, %xmm0
pextrb $0, %xmm0, %edx
instead of
pextrb $2, %xmm0, %esi
pextrb $0, %xmm0, %edx
addb %sil, %dl
pextrb $4, %xmm0, %esi
addb %dl, %sil
pextrb $6, %xmm0, %edx
addb %sil, %dl
pextrb $8, %xmm0, %esi
addb %dl, %sil
pextrb $10, %xmm0, %edi
pextrb $14, %xmm0, %edx
addb %sil, %dil
pextrb $12, %xmm0, %esi
addb %dil, %sil
addb %sil, %dl
llvm-svn: 170439
|
| |
|
|
| |
llvm-svn: 170416
|
| |
|
|
|
|
| |
getScalarSizeInBits could not handle vectors of pointers.
llvm-svn: 170412
|
| |
|
|
| |
llvm-svn: 170404
|
| |
|
|
|
|
|
|
| |
This was a silly oversight, we weren't pruning allocas which were used
by variable-length memory intrinsics from the set that could be widened
and promoted as integers. Fix that.
llvm-svn: 170353
|
| |
|
|
| |
llvm-svn: 170347
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also cleans up a bit of the memcpy call rewriting by sinking some
irrelevant code further down and making the call-emitting code a bit
more concrete.
Previously, memcpy of a subvector would actually miscompile (!!!) the
copy into a single vector element copy. I have no idea how this ever
worked. =/ This is the memcpy half of PR14478 which we probably weren't
noticing previously because it didn't actually assert.
The rewrite relies on the newly refactored insert- and extractVector
functions to do the heavy lifting, and those are the same as used for
loads and stores which makes the test coverage a bit more meaningful
here.
llvm-svn: 170338
|
| |
|
|
|
|
|
|
| |
Check whether a BB is known as reachable before adding it to the worklist.
This way BB's with multiple predecessors are added to the list no more than
once.
llvm-svn: 170335
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The first half of fixing this bug was actually in r170328, but was
entirely coincidental. It did however get me to realize the nature of
the bug, and adapt the test case to test more interesting behavior. In
turn, that uncovered the rest of the bug which I've fixed here.
This should fix two new asserts that showed up in the vectorize nightly
tester.
llvm-svn: 170333
|
| |
|
|
|
|
|
|
| |
I noticed this while looking at r170328. We only ever do a vector
rewrite when the alloca *is* the vector type, so it's good to not paper
over bugs here by doing a convertValue that isn't needed.
llvm-svn: 170331
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will allow its use inside of memcpy rewriting as well. This routine
is more complex than extractVector, and some of its uses are not 100%
where I want them to be so there is still some work to do here.
While this can technically change the output in some cases, it shouldn't
be a change that matters -- IE, it can leave some dead code lying around
that prior versions did not, etc.
Yet another step in the refactorings leading up to the solution to the
last component of PR14478.
llvm-svn: 170328
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The method helpers all implicitly act upon the alloca, and what we
really want is a fully generic helper. Doing memcpy rewrites is more
special than all other rewrites because we are at times rewriting
instructions which touch pointers *other* than the alloca. As
a consequence all of the helpers needed by memcpy rewriting of
sub-vector copies will need to be generalized fully.
Note that all of these helpers ({insert,extract}{Integer,Vector}) are
woefully uncommented. I'm going to go back through and document them
once I get the factoring correct.
No functionality changed.
llvm-svn: 170325
|