| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
| 
| 
|  | 
integer-promoted.
llvm-svn: 147484
 | 
| | 
| 
| 
| 
| 
| 
|  | 
then a vxorps + vinsertf128 pair if the original vector came from a load.
rdar://10594409
llvm-svn: 147481
 | 
| | 
| 
| 
| 
| 
|  | 
if-statement by turning it into an assert. No functionality change.
llvm-svn: 147474
 | 
| | 
| 
| 
| 
| 
|  | 
Targets can perfects well support intrinsics on illegal types, as long as they are prepared to perform custom expansion during type legalization.  For example, a target where i64 is illegal might still support the i64 intrinsic operation using pairs of i32's.  ARM already does some expansions like this for non-intrinsic operations.
llvm-svn: 147472
 | 
| | 
| 
| 
|  | 
llvm-svn: 147471
 | 
| | 
| 
| 
|  | 
llvm-svn: 147470
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
If anybody has strong feelings about 'default: assert(0 && "blah")' vs
'default: llvm_unreachable("blah")', feel free to regularize the instances of
each in this file.
llvm-svn: 147459
 | 
| | 
| 
| 
|  | 
llvm-svn: 147456
 | 
| | 
| 
| 
|  | 
llvm-svn: 147454
 | 
| | 
| 
| 
|  | 
llvm-svn: 147453
 | 
| | 
| 
| 
|  | 
llvm-svn: 147446
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The failure seen on win32, when i64 type is illegal.
It happens on stage of conversion VECTOR_SHUFFLE to BUILD_VECTOR.
The failure message is:
llc: SelectionDAG.cpp:784: void VerifyNodeCommon(llvm::SDNode*): Assertion `(I->getValueType() == EltVT || (EltVT.isInteger() && I->getValueType().isInteger() && EltVT.bitsLE(I->getValueType()))) && "Wrong operand type!"' failed.
I added a special test that checks vector shuffle on win32.
llvm-svn: 147445
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
"phony" insertion point.
Fixes rdar://10619599: "SelectionDAGBuilder shouldn't visit PHI nodes!" assert
llvm-svn: 147439
 | 
| | 
| 
| 
|  | 
llvm-svn: 147435
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
is testing the bitcode reader's functionality, not VMCore's. Add the
what is a hope sufficient build system mojo to build and run a new
unittest.
Also clean up some of the test's naming. The goal for the file should be
to unittest the Bitcode Reader, and this is just one particular test
among potentially many in the future. Also, reverse my position and
relegate the PR# to a comment, but stash the comment on the same line as
the test name so it doesn't get lost. This makes the code more
self-documenting hopefully w/o losing track of the PR number.
llvm-svn: 147431
 | 
| | 
| 
| 
| 
| 
|  | 
converting the indexing loops to unsigned to be consistent across functions.
llvm-svn: 147430
 | 
| | 
| 
| 
| 
| 
|  | 
Also make it return false if there's not even a load at all. This makes the code better match the code in DAGCombiner that it tries to match. These two changes prevent some cases where vector_shuffles were making it to instruction selection and causing the older shuffle selection code to be triggered. Also needed to fix a bad pattern that this change exposed. This is the first step towards getting rid of the old shuffle selection support. No test cases yet because there's no way to tell whether a shuffle was handled in the legalize stage or at instruction selection.
llvm-svn: 147428
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
build. This didn't show up in the CMake build because the CMake build
for the unittests is rather poorly factored.
This probably isn't the correct fix. This should be a bitcode reader
unittest not a VMCore unittest. I'll move it and clean various parts of
the unittest up in a follow-up patch, but I wanted to unbreak the bots.
llvm-svn: 147427
 | 
| | 
| 
| 
| 
| 
|  | 
instructions only look at the highest bit.
llvm-svn: 147426
 | 
| | 
| 
| 
| 
| 
|  | 
PR11677.
llvm-svn: 147425
 | 
| | 
| 
| 
|  | 
llvm-svn: 147411
 | 
| | 
| 
| 
| 
| 
|  | 
is enabled. Fix monitor and mwait to require SSE3 or AVX, previously they worked even if SSE3 was disabled. Make prefetch instructions not set the execution domain since they don't use XMM registers.
llvm-svn: 147409
 | 
| | 
| 
| 
|  | 
llvm-svn: 147404
 | 
| | 
| 
| 
| 
| 
|  | 
it to simplify a few matchers.
llvm-svn: 147403
 | 
| | 
| 
| 
|  | 
llvm-svn: 147402
 | 
| | 
| 
| 
|  | 
llvm-svn: 147400
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The failure seen on win32, when i64 type is illegal.
It happens on stage of conversion VECTOR_SHUFFLE to BUILD_VECTOR.
The failure message is:
llc: SelectionDAG.cpp:784: void VerifyNodeCommon(llvm::SDNode*): Assertion `(I->getValueType() == EltVT || (EltVT.isInteger() && I->getValueType().isInteger() && EltVT.bitsLE(I->getValueType()))) && "Wrong operand type!"' failed.
I added a special test that checks vector shuffle on win32.
llvm-svn: 147399
 | 
| | 
| 
| 
|  | 
llvm-svn: 147395
 | 
| | 
| 
| 
|  | 
llvm-svn: 147394
 | 
| | 
| 
| 
|  | 
llvm-svn: 147393
 | 
| | 
| 
| 
| 
| 
|  | 
a load from being selected.
llvm-svn: 147392
 | 
| | 
| 
| 
| 
| 
| 
|  | 
'and' that would zero out the trailing bits, and to produce an exact shift
ourselves.
llvm-svn: 147391
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
See PR11652. Trying to add this assert to
setSubclassData() itself actually prevented
the miscompile entirely, so it has to be here.
This makes the source of the bug more obvious
than the other asserts triggering later on did.
llvm-svn: 147390
 | 
| | 
| 
| 
|  | 
llvm-svn: 147383
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Implement encoder methods getJumpTargetOpValue and getBranchTargetOpValue
for jmptarget and brtarget Mips tablegen operand types in the code emitter
for old-style JIT. Rename the pc relative relocation for branches - new
name is Mips::reloc_mips_pc16.
Patch by Sasa Stankovic
llvm-svn: 147382
 | 
| | 
| 
| 
|  | 
llvm-svn: 147379
 | 
| | 
| 
| 
| 
| 
|  | 
removing from Bulldozer CPU types since it would enable AVX code generation implicitly. Also make SSE4A imply SSE3. Without some level of SSE implied, XMM registers wouldn't be legal.
llvm-svn: 147369
 | 
| | 
| 
| 
|  | 
llvm-svn: 147368
 | 
| | 
| 
| 
|  | 
llvm-svn: 147367
 | 
| | 
| 
| 
| 
| 
|  | 
of having the W bit set for XOP instructons. Removes ORing W-bits in the encoder and will similarly simplify the disassembler implementation.
llvm-svn: 147366
 | 
| | 
| 
| 
|  | 
llvm-svn: 147365
 | 
| | 
| 
| 
|  | 
llvm-svn: 147364
 | 
| | 
| 
| 
| 
| 
|  | 
force alignment on these instructions. Add a couple testcases for memory forms.
llvm-svn: 147361
 | 
| | 
| 
| 
| 
| 
|  | 
size, but with the special handling to be compatible with the intrinsic expecting a vector. Similar handling is already used elsewhere.
llvm-svn: 147360
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
1. The ST*UX instructions that store and update the stack pointer did not set define/kill on R1. This became a problem when I activated post-RA scheduling (and had incorrectly adjusted the Frames-large test).
2. eliminateFrameIndex did not kill its scavenged temporary register, and this could cause the scavenger to exhaust all available registers (and its emergency spill slot) when there were a lot of CR values to spill. The 2010-02-12-saveCR test has been adjusted to check for this.
llvm-svn: 147359
 | 
| | 
| 
| 
|  | 
llvm-svn: 147356
 | 
| | 
| 
| 
|  | 
llvm-svn: 147354
 | 
| | 
| 
| 
| 
| 
|  | 
instructions.
llvm-svn: 147353
 | 
| | 
| 
| 
|  | 
llvm-svn: 147352
 | 
| | 
| 
| 
|  | 
llvm-svn: 147351
 |