| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 145267
|
| |
|
|
| |
llvm-svn: 145263
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 145060
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 144886
|
| |
|
|
|
|
| |
LOAD+EXTRACT_VECTOR_ELT into a single LOAD. Fixes PR10747/PR11393.
llvm-svn: 144863
|
| |
|
|
|
|
| |
target-independent selector or the target-specific selector.
llvm-svn: 144833
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 144832
|
| |
|
|
| |
llvm-svn: 144768
|
| |
|
|
|
|
| |
indexed loads/stores to the legalizer.
llvm-svn: 144767
|
| |
|
|
| |
llvm-svn: 144747
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
%arrayidx135 = getelementptr inbounds [4 x [4 x [4 x [4 x i32]]]]* %M0, i32 0, i64 0
%arrayidx136 = getelementptr inbounds [4 x [4 x [4 x i32]]]* %arrayidx135, i32 0, i64 %idxprom134
Prior to this commit, the GEP instruction that defines %arrayidx136 thought that
%arrayidx135 was a trivial kill. The GEP that defines %arrayidx135 doesn't
generate any code and thus %M0 gets folded into the second GEP. Thus, we need
to look through GEPs with all zero indices.
rdar://10443319
llvm-svn: 144730
|
| |
|
|
|
|
|
|
|
|
|
|
| |
registers is used
by later instructions.
Only done for DEC64m right now.
Fixes <rdar://problem/6172640>
llvm-svn: 144705
|
| |
|
|
| |
llvm-svn: 144648
|
| |
|
|
| |
llvm-svn: 144647
|
| |
|
|
| |
llvm-svn: 144634
|
| |
|
|
|
|
| |
runs. Fixes PR11029.
llvm-svn: 144438
|
| |
|
|
|
|
|
|
| |
maintain LegalizeDAG invariants, whenever we a node is replaced, we must attempt to delete it, and if it still
has uses after it is replaced (which can happen in rare cases due to CSE), we must revisit it.
llvm-svn: 144432
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instruction lower optimization" in the pre-RA scheduler.
The optimization, rather the hack, was done before MI use-list was available.
Now we should be able to implement it in a better way, perhaps in the
two-address pass until a MI scheduler is available.
Now that the scheduler has to backtrack to handle call sequences. Adding
artificial scheduling constraints is just not safe. Furthermore, the hack
is not taking all the other scheduling decisions into consideration so it's just
as likely to pessimize code. So I view disabling this optimization goodness
regardless of PR11314.
llvm-svn: 144267
|
| |
|
|
|
|
| |
issue from PR11319.
llvm-svn: 144216
|