- Dec 17, 2012
-
-
Chad Rosier authored
llvm-svn: 170379
-
Nick Kledzik authored
llvm-svn: 170376
-
Chandler Carruth authored
llvm-svn: 170374
-
Chandler Carruth authored
compilation directory. This defaults to the current working directory, just as it always has, but now an assembler can choose to override it with a custom directory. I've taught llvm-mc about this option and added a test case. llvm-svn: 170371
-
Nick Kledzik authored
llvm-svn: 170369
-
Michael Ilseman authored
llvm-svn: 170368
-
Michael Ilseman authored
llvm-svn: 170367
-
Chad Rosier authored
checks are in place. Some minor cleanup as well. llvm-svn: 170360
-
Nick Kledzik authored
llvm-svn: 170355
-
Chandler Carruth authored
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
-
Tim Northover authored
llvm-svn: 170350
-
Tim Northover authored
llvm-svn: 170349
-
Evgeniy Stepanov authored
llvm-svn: 170347
-
Richard Osborne authored
llvm-svn: 170345
-
Tom Stellard authored
They seem to work fine. Patch by: Christian König Reviewed-by:
Tom Stellard <thomas.stellard@amd.com> Tested-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Christian König <deathsimple@vodafone.de> llvm-svn: 170343
-
Tom Stellard authored
Patch by: Christian König Reviewed-by:
Tom Stellard <thomas.stellard@amd.com> Tested-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Christian König <deathsimple@vodafone.de> llvm-svn: 170342
-
Tom Stellard authored
The Align parameter is a power of two, so 16 results in 64K alignment. Additional to that even 16 byte alignment doesn't make any sense, so just remove it. Patch by: Christian König Reviewed-by:
Tom Stellard <thomas.stellard@amd.com> Tested-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Christian König <deathsimple@vodafone.de> llvm-svn: 170341
-
Chandler Carruth authored
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
-
Patrik Hagglund authored
TargetLowering::getRegClassFor). Some isSimple() guards were missing, or getSimpleVT() were hoisted too far, resulting in asserts on valid LLVM assembly input. llvm-svn: 170336
-
Evgeniy Stepanov authored
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
-
Richard Osborne authored
Previously these were marked with the wrong format. llvm-svn: 170334
-
Chandler Carruth authored
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
-
Richard Osborne authored
llvm-svn: 170332
-
Chandler Carruth authored
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
-
Richard Osborne authored
llvm-svn: 170330
-
Chandler Carruth authored
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
-
Richard Osborne authored
Previously these were marked with the wrong format. llvm-svn: 170327
-
Chandler Carruth authored
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
-
Chandler Carruth authored
This makes it suitable for use in rewriting memcpy in the presence of subvector memcpy intrinsics. No functionality changed. llvm-svn: 170324
-
Richard Osborne authored
llvm-svn: 170323
-
Richard Osborne authored
llvm-svn: 170322
-
Richard Osborne authored
llvm-svn: 170321
-
Richard Osborne authored
llvm-svn: 170320
-
Richard Osborne authored
llvm-svn: 170319
-
Duncan Sands authored
Patch by Chris Toshok. llvm-svn: 170318
-
Duncan Sands authored
llvm-svn: 170317
-
Craig Topper authored
Remove EFLAGS from the BLSI/BLSMSK/BLSR patterns. The nodes created by DAG combine don't contain an EFLAGS def. llvm-svn: 170308
-
Craig Topper authored
Simplify BMI ANDN matching to use patterns instead of a DAG combine. Also add ANDN to isDefConvertible. llvm-svn: 170305
-
Craig Topper authored
llvm-svn: 170304
-
Craig Topper authored
Remove store forms of DEC/INC from isDefConvertible. Since they are stores they don't have a register def. llvm-svn: 170303
-