| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
If a 1-bit value is in a 32-bit VGPR, the scalar opcodes set SCC to
whether the result is 0. If the inputs are SCC, these can be copied to
a 32-bit SGPR to produce an SCC result.
llvm-svn: 366125
|
| |
|
|
| |
llvm-svn: 366121
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a hack until I come up with a better way of dealing with the
pseudo-register banks used for boolean values. If the use instruction
constrains the register, the selector for the def instruction won't
see that the bank was VCC. A 1-bit SReg_32 is could ambiguously have
been SCCRegBank or VCCRegBank in wave32.
This is necessary to successfully select branches with and and/or/xor
condition.
llvm-svn: 366120
|
| |
|
|
|
|
|
|
|
| |
The extra test change is correct, although how it arrives there is a
bug that needs work. With wave32, the test for isVCC ambiguously
reports true for an SCC or VCC source. A new allocatable pseudo
register class for SCC may be necesssary.
llvm-svn: 366119
|
| |
|
|
| |
llvm-svn: 366118
|
| |
|
|
|
|
| |
This was emitting a copy from a 32-bit register to a 64-bit.
llvm-svn: 366117
|
| |
|
|
| |
llvm-svn: 366116
|
| |
|
|
|
|
| |
Turn the constant cases into G_EXTRACTs.
llvm-svn: 366115
|
| |
|
|
| |
llvm-svn: 366114
|
| |
|
|
| |
llvm-svn: 366103
|
| |
|
|
| |
llvm-svn: 366102
|
| |
|
|
| |
llvm-svn: 366099
|
| |
|
|
|
|
|
|
|
|
|
| |
Insert these during codegenprepare.
This works around a DAG issue where generic combines eliminate the and
asserting the high bits are zero, which then exposes an unknown read
source to the mul combine. It doesn't worth the hassle of trying to
insert an AssertZext or something to try to deal with it.
llvm-svn: 366094
|
| |
|
|
|
|
|
|
| |
NFC at the momemnt, needed for future commit.
Differential Revision: https://reviews.llvm.org/D64761
llvm-svn: 366092
|
| |
|
|
| |
llvm-svn: 366087
|
| |
|
|
| |
llvm-svn: 366086
|
| |
|
|
|
|
|
|
|
| |
For some reason scheduler can send down an SUnit without an
instruction.
Differential Revision: https://reviews.llvm.org/D64709
llvm-svn: 366074
|
| |
|
|
|
|
|
|
| |
Reviewers: artem.tamazov, arsenm
Differential Revision: https://reviews.llvm.org/D64729
llvm-svn: 366071
|
| |
|
|
|
|
|
|
|
|
| |
See bug 42599: https://bugs.llvm.org/show_bug.cgi?id=42599
Reviewers: artem.tamazov, arsenm
Differential Revision: https://reviews.llvm.org/D64716
llvm-svn: 366067
|
| |
|
|
| |
llvm-svn: 366041
|
| |
|
|
|
|
|
|
|
| |
These should really use v32f32, but were defined as v32i32
due to the lack of the v32f32 type.
Differential Revision: https://reviews.llvm.org/D64667
llvm-svn: 365972
|
| |
|
|
|
|
|
|
| |
Before 2018, mesa used to use byval interchangably with inreg, which
didn't really make sense. Fix tests still using it to avoid breaking
in a future commit.
llvm-svn: 365953
|
| |
|
|
|
|
|
|
|
|
| |
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64657
llvm-svn: 365952
|
| |
|
|
|
|
|
|
| |
This is NFC, but required for future commit.
Differential Revision: https://reviews.llvm.org/D64649
llvm-svn: 365940
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
r363675 changed the exec modification helper function, now called
execMayBeModifiedBeforeUse, so that if no UseMI is specified it checks
all instructions in the basic block, even beyond the last use. That
meant that the DPP combiner no longer worked in any basic block that
ended with a control flow instruction, and in particular it didn't work
on code sequences generated by the atomic optimizer.
Fix it by reinstating the old behaviour but in a new helper function
execMayBeModifiedBeforeAnyUse, and limiting the number of instructions
scanned.
Reviewers: arsenm, vpykhtin
Subscribers: kzhuravl, nemanjai, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, kbarton, MaskRay, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64393
llvm-svn: 365910
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
D64497 allowed abs/neg source modifiers on v_cndmask_b32 but it doesn't
make any sense to apply them to f16 operands; they would interpret the
bits of the value as an f32, giving nonsensical results. This patch
restricts them to f32 operands.
Reviewers: arsenm, hakzsam
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64636
llvm-svn: 365904
|
| |
|
|
| |
llvm-svn: 365903
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64596
llvm-svn: 365846
|
| |
|
|
|
|
|
| |
Also make it an ImmLeaf, so it should work with global isel as well,
which was part of the point of moving it in the first place.
llvm-svn: 365842
|
| |
|
|
|
|
| |
Instruction was used after it was erased.
llvm-svn: 365837
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D64594
llvm-svn: 365833
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D64593
llvm-svn: 365829
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D64590
llvm-svn: 365826
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D64584
llvm-svn: 365824
|
| |
|
|
| |
llvm-svn: 365782
|
| |
|
|
| |
llvm-svn: 365741
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D64435
llvm-svn: 365717
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D64431
llvm-svn: 365715
|
| |
|
|
| |
llvm-svn: 365658
|
| |
|
|
| |
llvm-svn: 365653
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
D59191 added support for these modifiers in the assembler and
disassembler. This patch just teaches instruction selection that it can
use them.
Reviewers: arsenm, tstellar
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64497
llvm-svn: 365640
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D64433
llvm-svn: 365573
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D64446
llvm-svn: 365563
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isLoadBitCastBeneficial/isStoreBitCastBeneficial to allow X86 to bypass it
Basically the problem is that X86 doesn't set the Fast flag from
allowsMemoryAccess on certain CPUs due to slow unaligned memory
subtarget features. This prevents bitcasts from being folded into
loads and stores. But all vector loads and stores of the same width
are the same cost on X86.
This patch merges the allowsMemoryAccess call into isLoadBitCastBeneficial to allow X86 to skip it.
Differential Revision: https://reviews.llvm.org/D64295
llvm-svn: 365549
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D64438
llvm-svn: 365546
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D64429
llvm-svn: 365525
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
return instruction.
Function return instruction lowering, currently uses the fixed register pair s[30:31] for holding
the return address. It can be any SGPR pair other than the CSRs. Created an SGPR pair sub-register class
exclusive of the CSRs, and used this regclass while lowering the return instruction.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D63924
llvm-svn: 365512
|