| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 366621
|
| |
|
|
|
|
|
|
| |
Now that the patterns use the new PatFrag address space support, the
only blocker to importing most load patterns is the addressing mode
complex patterns.
llvm-svn: 366237
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Apparently the check for legal instructions during instruction
select does not happen without an asserts build, so these would
successfully select in release, and fail in debug.
Make s16 and/or/xor legal. These can just be selected directly
to the 32-bit operation, as is already done in SelectionDAG, so just
make them legal.
llvm-svn: 366210
|
| |
|
|
| |
llvm-svn: 366116
|
| |
|
|
|
|
| |
Turn the constant cases into G_EXTRACTs.
llvm-svn: 366115
|
| |
|
|
| |
llvm-svn: 366103
|
| |
|
|
| |
llvm-svn: 365658
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds support for the most commonly used wide load types:
<8xi32>, <16xi32>, <4xi64>, and <8xi64>
Reviewers: arsenm
Reviewed By: arsenm
Subscribers: hiraditya, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, rovka, kristof.beyls, dstuttard, tpr, t-tye, volkan, Petar.Avramovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57399
llvm-svn: 365586
|
| |
|
|
|
|
|
|
|
| |
In SelectionDAG AMDGPU treated these as legal, but this was mostly
because the bitcasts required for FP types were painful. Theoretically
the bitpattern should eventually match to bfi, so don't bother trying
to get the patterns to import.
llvm-svn: 365583
|
| |
|
|
| |
llvm-svn: 365575
|
| |
|
|
| |
llvm-svn: 365488
|
| |
|
|
| |
llvm-svn: 365486
|
| |
|
|
| |
llvm-svn: 365482
|
| |
|
|
| |
llvm-svn: 364836
|
| |
|
|
| |
llvm-svn: 364835
|
| |
|
|
| |
llvm-svn: 364834
|
| |
|
|
|
|
|
|
|
| |
Tests don't cover the masked input path since non-kernel arguments
aren't lowered yet.
Test is copied directly from the existing test, with 2 additions.
llvm-svn: 364833
|
| |
|
|
|
|
|
|
| |
Replace the brcond for the 2 cases that act as branches. For now
follow how the current system works, although I think we can
eventually get rid of the pseudos.
llvm-svn: 364832
|
| |
|
|
|
|
|
| |
If this is scalar, promote to s32. Use a new observer class to assign
the register bank of newly created registers.
llvm-svn: 364827
|
| |
|
|
| |
llvm-svn: 364817
|
| |
|
|
|
|
|
| |
This is easy to handle and avoids legalization artifacts which are
likely to obscure combines.
llvm-svn: 364787
|
| |
|
|
| |
llvm-svn: 364616
|
| |
|
|
|
|
|
|
|
| |
Force using Register.
One downside is the generated register enums require explicit
conversion.
llvm-svn: 364194
|
| |
|
|
|
|
|
|
|
| |
Avoids using a plain unsigned for registers throughoug codegen.
Doesn't attempt to change every register use, just something a little
more than the set needed to build after changing the return type of
MachineOperand::getReg().
llvm-svn: 364191
|
| |
|
|
|
|
|
|
| |
This is incomplete, and ideally these would all be removed, but it's
better to localize them to the subtarget first with comments about
what they're for.
llvm-svn: 363902
|
| |
|
|
| |
llvm-svn: 361519
|
| |
|
|
| |
llvm-svn: 361082
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is ported from the custom AMDGPU DAG implementation. I think this
is a better default expansion than what the DAG currently uses, at
least if the target has CTLZ.
This implements the signed version in terms of the unsigned
conversion, which is implemented with bit operations. SelectionDAG has
several other implementations that should eventually be ported
depending on what instructions are legal.
llvm-svn: 361081
|
| |
|
|
| |
llvm-svn: 361030
|
| |
|
|
| |
llvm-svn: 361028
|
| |
|
|
| |
llvm-svn: 361027
|
| |
|
|
| |
llvm-svn: 361026
|
| |
|
|
| |
llvm-svn: 361025
|
| |
|
|
| |
llvm-svn: 358894
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constants only.
Other opcodes shouldn't be CSE'd until we can be sure debug info quality won't
be degraded.
This change also improves the IRTranslator so that in most places, but not all,
it creates constants using the MIRBuilder directly instead of first creating a
new destination vreg and then creating a constant. By doing this, the
buildConstant() method can just return the vreg of an existing G_CONSTANT
instead of having to create a COPY from it.
I measured a 0.2% improvement in compile time and a 0.9% improvement in code
size at -O0 ARM64.
Compile time:
Program base cse diff
test-suite...ark/tramp3d-v4/tramp3d-v4.test 9.04 9.12 0.8%
test-suite...Mark/mafft/pairlocalalign.test 2.68 2.66 -0.7%
test-suite...-typeset/consumer-typeset.test 5.53 5.51 -0.4%
test-suite :: CTMark/lencod/lencod.test 5.30 5.28 -0.3%
test-suite :: CTMark/Bullet/bullet.test 25.82 25.76 -0.2%
test-suite...:: CTMark/ClamAV/clamscan.test 6.92 6.90 -0.2%
test-suite...TMark/7zip/7zip-benchmark.test 34.24 34.17 -0.2%
test-suite :: CTMark/SPASS/SPASS.test 6.25 6.24 -0.1%
test-suite...:: CTMark/sqlite3/sqlite3.test 1.66 1.66 -0.1%
test-suite :: CTMark/kimwitu++/kc.test 13.61 13.60 -0.0%
Geomean difference -0.2%
Code size:
Program base cse diff
test-suite...-typeset/consumer-typeset.test 1315632 1266480 -3.7%
test-suite...:: CTMark/ClamAV/clamscan.test 1313892 1297508 -1.2%
test-suite :: CTMark/lencod/lencod.test 1439504 1423112 -1.1%
test-suite...TMark/7zip/7zip-benchmark.test 2936980 2904172 -1.1%
test-suite :: CTMark/Bullet/bullet.test 3478276 3445460 -0.9%
test-suite...ark/tramp3d-v4/tramp3d-v4.test 8082868 8033492 -0.6%
test-suite :: CTMark/kimwitu++/kc.test 3870380 3853972 -0.4%
test-suite :: CTMark/SPASS/SPASS.test 1434904 1434896 -0.0%
test-suite...Mark/mafft/pairlocalalign.test 764528 764528 0.0%
test-suite...:: CTMark/sqlite3/sqlite3.test 782092 782092 0.0%
Geomean difference -0.9%
Differential Revision: https://reviews.llvm.org/D60580
llvm-svn: 358369
|
| |
|
|
| |
llvm-svn: 357762
|
| |
|
|
| |
llvm-svn: 355048
|
| |
|
|
| |
llvm-svn: 355047
|
| |
|
|
| |
llvm-svn: 354825
|
| |
|
|
| |
llvm-svn: 354818
|
| |
|
|
| |
llvm-svn: 354592
|
| |
|
|
| |
llvm-svn: 354587
|
| |
|
|
|
|
| |
Also complete the set of related operations.
llvm-svn: 354480
|
| |
|
|
| |
llvm-svn: 354477
|
| |
|
|
| |
llvm-svn: 354354
|
| |
|
|
| |
llvm-svn: 354348
|
| |
|
|
| |
llvm-svn: 354345
|
| |
|
|
| |
llvm-svn: 354293
|
| |
|
|
|
|
|
| |
This allows targets to specify the minimum alignment required for the
load/store.
llvm-svn: 354071
|
| |
|
|
|
|
|
|
|
|
| |
This is basically a pointer typed add, so shouldn't be any different.
This was assuming everything was an SGPR, which is not true.
Also cleanup legality for GEP. I don't seem to be seeing the problem
the hack marking s64 as a legal pointer type the comment mentions.
llvm-svn: 354067
|