| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 147733
|
|
|
|
|
|
| |
subc, turn it into a sub. Turn (subc x, x) into 0 with no borrow. Turn (subc x, 0) into x with no borrow. Turn (subc -1, x) into (xor x, -1) with no borrow. Turn sube with no borrow in into subc.
llvm-svn: 147728
|
|
|
|
| |
llvm-svn: 147696
|
|
|
|
|
|
|
|
|
| |
a combined-away node and the result of the combine isn't substantially
smaller than the input, it's just canonicalized. This is the first part
of a significant (7%) performance gain for Snappy's hot decompression
loop.
llvm-svn: 147604
|
|
|
|
|
|
| |
are commuted in the shuffle mask.
llvm-svn: 147527
|
|
|
|
| |
llvm-svn: 147525
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before we'd get:
$ clang t.c
fatal error: error in backend: Invalid operand for inline asm constraint 'i'!
Now we get:
$ clang t.c
t.c:16:5: error: invalid operand for inline asm constraint 'i'!
"movq (%4), %%mm0\n"
^
Which at least gets us the inline asm that is the problem.
llvm-svn: 147502
|
|
|
|
|
|
| |
integer-promoted.
llvm-svn: 147484
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Promotion of the mask operand needs to be done using PromoteTargetBoolean, and not padded with garbage.
llvm-svn: 147309
|
|
|
|
|
|
| |
location. PR10747, part 2.
llvm-svn: 147283
|
|
|
|
| |
llvm-svn: 147272
|
|
|
|
| |
llvm-svn: 147197
|
|
|
|
| |
llvm-svn: 146986
|
|
|
|
|
|
| |
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146960
|
|
|
|
| |
llvm-svn: 146927
|
|
|
|
|
|
| |
attribute themselve.
llvm-svn: 146851
|
|
|
|
|
|
| |
Patch by Kyriakos Georgiou!
llvm-svn: 146670
|
|
|
|
|
|
| |
but the existing code can't do it correctly. PR11570.
llvm-svn: 146630
|
|
|
|
|
|
| |
These are already marked as illegal by default.
llvm-svn: 146623
|
|
|
|
| |
llvm-svn: 146548
|
|
|
|
|
|
| |
instructions that define aggregate types.
llvm-svn: 146492
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
undefined result. This adds new ISD nodes for the new semantics,
selecting them when the LLVM intrinsic indicates that the undef behavior
is desired. The new nodes expand trivially to the old nodes, so targets
don't actually need to do anything to support these new nodes besides
indicating that they should be expanded. I've done this for all the
operand types that I could figure out for all the targets. Owners of
various targets, please review and let me know if any of these are
incorrect.
Note that the expand behavior is *conservatively correct*, and exactly
matches LLVM's current behavior with these operations. Ideally this
patch will not change behavior in any way. For example the regtest suite
finds the exact same instruction sequences coming out of the code
generator. That's why there are no new tests here -- all of this is
being exercised by the existing test suite.
Thanks to Duncan Sands for reviewing the various bits of this patch and
helping me get the wrinkles ironed out with expanding for each target.
Also thanks to Chris for clarifying through all the discussions that
this is indeed the approach he was looking for. That said, there are
likely still rough spots. Further review much appreciated.
llvm-svn: 146466
|
|
|
|
| |
llvm-svn: 146453
|
|
|
|
| |
llvm-svn: 146409
|
|
|
|
|
|
| |
Disable while I investigate.
llvm-svn: 146331
|
|
|
|
| |
llvm-svn: 146327
|
|
|
|
|
|
| |
rdar://10530851
llvm-svn: 146276
|
|
|
|
| |
llvm-svn: 146219
|
|
|
|
|
|
| |
can use the former to prevent the formation of libm SDNode's when -fno-builtin is passed.
llvm-svn: 146193
|
|
|
|
| |
llvm-svn: 146186
|
|
|
|
|
|
| |
SDNodes. Mark these nodes as illegal by default, unless the target declares otherwise.
llvm-svn: 146171
|
|
|
|
|
|
|
| |
We must not issue a bitcast operation for integer-promotion of vector types, because the
location of the values in the vector may be different.
llvm-svn: 146150
|
|
|
|
|
|
| |
<rdar://problem/10460321>. No testcase because this is very sensitive to scheduling.
llvm-svn: 146087
|
|
|
|
|
|
| |
it's rather delicate.
llvm-svn: 146083
|
|
|
|
|
|
| |
that he isn't using these any more, so just delete them.
llvm-svn: 146076
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
generator to it. For non-bundle instructions, these behave exactly the same
as the MC layer API.
For properties like mayLoad / mayStore, look into the bundle and if any of the
bundled instructions has the property it would return true.
For properties like isPredicable, only return true if *all* of the bundled
instructions have the property.
For properties like canFoldAsLoad, isCompare, conservatively return false for
bundles.
llvm-svn: 146026
|
|
|
|
|
|
| |
doesn't affect any in-tree target.
llvm-svn: 146015
|
|
|
|
|
|
| |
correctly. PR11494.
llvm-svn: 145996
|
|
|
|
|
|
|
|
|
| |
1. Added opcode BUNDLE
2. Taught MachineInstr class to deal with bundled MIs
3. Changed MachineBasicBlock iterator to skip over bundled MIs; added an iterator to walk all the MIs
4. Taught MachineBasicBlock methods about bundled MIs
llvm-svn: 145975
|
|
|
|
| |
llvm-svn: 145801
|
|
|
|
|
|
|
|
|
|
|
|
| |
change, now you need a TargetOptions object to create a TargetMachine. Clang
patch to follow.
One small functionality change in PTX. PTX had commented out the machine
verifier parts in their copy of printAndVerify. That now calls the version in
LLVMTargetMachine. Users of PTX who need verification disabled should rely on
not passing the command-line flag to enable it.
llvm-svn: 145714
|
|
|
|
|
|
| |
attempt.
llvm-svn: 145425
|
|
|
|
| |
llvm-svn: 145420
|
|
|
|
|
|
| |
duplicating the logic for globals. Make llvm::ComputeMaskedBits handle GlobalVariables slightly more aggressively, to match what InferPtrAlignment knew how to do.
llvm-svn: 145304
|
|
|
|
|
|
|
|
|
|
|
| |
Conservatively returns zero when the GV does not specify an alignment nor is it
initialized. Previously it returns ABI alignment for type of the GV. However, if
the type is a "packed" type, then the under-specified alignments is attached to
the load / store instructions. In that case, the alignment of the type cannot be
trusted.
rdar://10464621
llvm-svn: 145300
|
|
|
|
|
|
|
|
|
| |
than ABI alignment. These are loads / stores from / to "packed" data structures.
Their alignments are intentionally under-specified.
rdar://10301431
llvm-svn: 145273
|