Age | Commit message (Collapse) | Author |
|
integer-promoted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147484 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147472 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147445 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147400 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147399 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Promotion of the mask operand needs to be done using PromoteTargetBoolean, and not padded with garbage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147309 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
location. PR10747, part 2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147283 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147272 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147197 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146986 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146960 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146927 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
attribute themselve.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146851 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Kyriakos Georgiou!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146670 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
but the existing code can't do it correctly. PR11570.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146630 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
These are already marked as illegal by default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146623 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146548 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instructions that define aggregate types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146492 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146466 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146453 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146409 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Disable while I investigate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146331 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146327 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://10530851
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146276 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146219 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
can use the former to prevent the formation of libm SDNode's when -fno-builtin is passed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146193 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146186 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
SDNodes. Mark these nodes as illegal by default, unless the target declares otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146171 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146150 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
<rdar://problem/10460321>. No testcase because this is very sensitive to scheduling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146087 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
it's rather delicate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146083 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that he isn't using these any more, so just delete them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146076 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146026 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
doesn't affect any in-tree target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146015 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
correctly. PR11494.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145996 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145975 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145801 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145714 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
attempt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145425 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145420 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
duplicating the logic for globals. Make llvm::ComputeMaskedBits handle GlobalVariables slightly more aggressively, to match what InferPtrAlignment knew how to do.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145304 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145300 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
than ABI alignment. These are loads / stores from / to "packed" data structures.
Their alignments are intentionally under-specified.
rdar://10301431
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145273 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145267 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145263 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
dropping weights on the floor for invokes. This was impeding my writing
further test cases for invoke when interacting with probabilities and
block placement.
No test case as there doesn't appear to be a way to test this stuff. =/
Suggestions for a test case of course welcome. I hope to be able to add
test cases that indirectly cover this eventually by adding probabilities
to the exceptional edge and reordering blocks as a result.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145060 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ADDs. MaxOffs is used as a threshold to limit the size of the offset. Tradeoffs
being: (1) If we can't materialize the large constant then we'll cause fast-isel
to bail. (2) Too large of an offset can't be directly encoded in the ADD
resulting in a MOV+ADD. Generally not a bad thing because otherwise we would
have had ADD+ADD, but on Thumb this turns into a MOVS+MOVT+ADD. Working on a fix
for that. (3) Conversely, too low of a threshold we'll miss opportunities to
coalesce ADDs.
rdar://10412592
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144886 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LOAD+EXTRACT_VECTOR_ELT into a single LOAD. Fixes PR10747/PR11393.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144863 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
target-independent selector or the target-specific selector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144833 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
for a single miss and not all predecessor instructions that get selected by
the selection DAG instruction selector. This is still not exact (e.g., over
states misses when folded/dead instructions are present), but it is a step in
the right direction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144832 91177308-0d34-0410-b5e6-96231b3b80d8
|