| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Issue: https://github.com/GPUOpen-Drivers/llpc/issues/204
Reviewers: arsenm, rampitec
Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68184
llvm-svn: 374041
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When getValueInMiddleOfBlock happens to be called for a basic block
that has no incoming value at all, an IMPLICIT_DEF is inserted in that
block via GetValueAtEndOfBlockInternal. This IMPLICIT_DEF must be at
the top of its basic block or it will likely not reach the use that
the caller intends to insert.
Issue: https://github.com/GPUOpen-Drivers/llpc/issues/204
Reviewers: arsenm, rampitec
Subscribers: jvesely, wdng, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68183
llvm-svn: 374040
|
|
|
|
| |
llvm-svn: 373989
|
|
|
|
|
|
|
|
|
| |
Start manually writing a table to get the subreg index. TableGen
should probably generate this, but I'm not sure what it looks like in
the arbitrary case where subregisters are allowed to not fully cover
the super-registers.
llvm-svn: 373947
|
|
|
|
| |
llvm-svn: 373946
|
|
|
|
| |
llvm-svn: 373945
|
|
|
|
| |
llvm-svn: 373944
|
|
|
|
|
|
|
| |
This hides some defects in SIFoldOperands when the immediates are
split.
llvm-svn: 373943
|
|
|
|
|
|
| |
Continue making a mess of merge/unmerge legality.
llvm-svn: 373942
|
|
|
|
|
|
|
|
|
|
| |
At minimum handle the s64 insert type, which are emitted in real cases
during legalization.
We really need TableGen to emit something to emit something like the
inverse of composeSubRegIndices do determine the subreg index to use.
llvm-svn: 373938
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allows targets to introduce regbankselectable
pseudo-instructions. Currently the closet feature to this is an
intrinsic. However this requires creating a public intrinsic
declaration. This litters the public intrinsic namespace with
operations we don't necessarily want to expose to IR producers, and
would rather leave as private to the backend.
Use a new instruction bit. A previous attempt tried to keep using enum
value ranges, but it turned into a mess.
llvm-svn: 373937
|
|
|
|
|
|
|
|
| |
The GFX10-DENORM-STRICT checks were only passing by accident. Fix them
to make the test more robust in the face of scheduling or register
allocation changes.
llvm-svn: 373893
|
|
|
|
| |
llvm-svn: 373840
|
|
|
|
| |
llvm-svn: 373839
|
|
|
|
|
|
| |
Turn into shift and truncate. Doesn't yet handle pointers.
llvm-svn: 373838
|
|
|
|
|
|
| |
This wasn't updated for the immarg handling change.
llvm-svn: 373837
|
|
|
|
|
|
|
| |
This was always passing the destination flat address space, when it
should be picking between the two valid source options.
llvm-svn: 373716
|
|
|
|
| |
llvm-svn: 373715
|
|
|
|
| |
llvm-svn: 373714
|
|
|
|
| |
llvm-svn: 373639
|
|
|
|
|
|
|
|
| |
Register indexing 64-bit elements is possible on the SALU, but not the
VALU. Handle splitting this into two 32-bit indexes. Extend waterfall
loop handling to allow moving a range of instructions.
llvm-svn: 373638
|
|
|
|
|
|
|
|
| |
We can still do a waterfall loop over the index if using a VGPR to
index an SGPR. The result will still be a VGPR, but we can avoid the
wide copy of the source register to a VGPR.
llvm-svn: 373637
|
|
|
|
| |
llvm-svn: 373636
|
|
|
|
|
|
| |
This would try to do FewerElements to v9s8
llvm-svn: 373635
|
|
|
|
| |
llvm-svn: 373567
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When SIFixSGPRCopies attempts to fix an illegal copy from vector to
scalar register it calls moveToVALU(). A copy from an agpr to sgpr
becomes a copy from agpr to agpr, which may result in the illegal
register class at a use of this copy.
Solution is to copy it always into a vgpr. This may result in a
subsequent copy into an agpr if that is what really needed, however
should not happen too often and likely will be folded later.
The opposite situation may not happen because an sgpr is always
illegal where agpr is legal, so such user instructions may not
exist.
Differential Revision: https://reviews.llvm.org/D68358
llvm-svn: 373544
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Extend cachepolicy operand in the new VMEM buffer intrinsics
to supply information whether the buffer data is swizzled.
Also, propagate this information to MIR.
Intrinsics updated:
int_amdgcn_raw_buffer_load
int_amdgcn_raw_buffer_load_format
int_amdgcn_raw_buffer_store
int_amdgcn_raw_buffer_store_format
int_amdgcn_raw_tbuffer_load
int_amdgcn_raw_tbuffer_store
int_amdgcn_struct_buffer_load
int_amdgcn_struct_buffer_load_format
int_amdgcn_struct_buffer_store
int_amdgcn_struct_buffer_store_format
int_amdgcn_struct_tbuffer_load
int_amdgcn_struct_tbuffer_store
Furthermore, disable merging of VMEM buffer instructions
in SI Load/Store optimizer, if the "swizzled" bit on the instruction
is on.
The default value of the bit is 0, meaning that data in buffer
is linear and buffer instructions can be merged.
There is no difference in the generated code with this commit.
However, in the future it will be expected that front-ends
use buffer intrinsics with correct "swizzled" bit set.
Reviewers: arsenm, nhaehnle, tpr
Reviewed By: nhaehnle
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, arphaman, jfb, Petar.Avramovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68200
llvm-svn: 373491
|
|
|
|
|
|
|
|
|
| |
In principle this should behave as any other constant. However
eliminateFrameIndex currently assumes a VALU use and uses a vector
shift. Work around this by selecting to VGPR for now until
eliminateFrameIndex is fixed.
llvm-svn: 373415
|
|
|
|
| |
llvm-svn: 373414
|
|
|
|
|
|
| |
This will be needed to support AGPR operations.
llvm-svn: 373413
|
|
|
|
| |
llvm-svn: 373412
|
|
|
|
|
|
|
|
|
| |
Account and report agprs separately on gfx908. Other targets
do not change the reporting.
Differential Revision: https://reviews.llvm.org/D68307
llvm-svn: 373411
|
|
|
|
|
|
|
|
|
|
| |
Reviewers:
arsenm
Differential Revision:
https://reviews.llvm.org/D67574
llvm-svn: 373404
|
|
|
|
|
|
|
|
| |
There are 1024 bit register classes defined for AGPRs. Additionally
OpenCL defines vectors up to 16 x i64, and this helps those tests
legalize.
llvm-svn: 373350
|
|
|
|
|
|
|
|
| |
This reverts commit r373294. It broke Clang's
CodeGen/arm64-microsoft-status-reg.cpp:
http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/18483
llvm-svn: 373310
|
|
|
|
| |
llvm-svn: 373298
|
|
|
|
|
|
|
| |
TThe existing wave32 behavior seems broken and incomplete, but this
reproduces it.
llvm-svn: 373296
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SelectionDAG has a bunch of machinery to defer this to selection time
for some reason. Just directly emit a copy during IRTranslator. The
x86 usage does somewhat questionably check hasFP, which could depend
on the whole function being at minimum translated.
This does lose the convergent bit if the callsite had it, which may be
a problem. We also lose that in general for intrinsics, which may also
be a problem.
llvm-svn: 373294
|
|
|
|
|
|
|
|
| |
This is sort of papering over the fact that we don't run a combiner
anywhere, but avoiding creating 2 instructions in the first place is
easy.
llvm-svn: 373293
|
|
|
|
| |
llvm-svn: 373288
|
|
|
|
|
|
| |
Legalize 16-bit G_SITOFP/G_UITOFP for AMDGPU.
llvm-svn: 373287
|
|
|
|
|
|
|
| |
Handle other cases besides LDS. Mostly a straight port of the existing
handling, without the intermediate custom nodes.
llvm-svn: 373286
|
|
|
|
|
|
|
|
| |
Reviewers: rampitec
Differential Revision: https://reviews.llvm.org/D67662
llvm-svn: 373221
|
|
|
|
|
|
|
|
|
|
| |
ISD::SADDO uses the suggested sequence described in the section ยง2.4 of
the RISCV Spec v2.2. ISD::SSUBO uses the dual approach but checking for
(non-zero) positive.
Differential Revision: https://reviews.llvm.org/D47927
llvm-svn: 373187
|
|
|
|
| |
llvm-svn: 373180
|
|
|
|
| |
llvm-svn: 372908
|
|
|
|
|
|
|
|
| |
Fold immediates into v_fmac_f16.
Differential Revision: https://reviews.llvm.org/D68037
llvm-svn: 372906
|
|
|
|
|
|
|
|
|
| |
I believe all of the uniform/divergent pattern predicates are
redundant and can be removed. The uniformity bit already influences
the register class, and nothhing has broken when I've removed this and
others.
llvm-svn: 372450
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the documentation method returns predecessor
if the given loop's header has exactly one unique predecessor
outside the loop. Otherwise return null.
In reality it asserts if there is no predecessor outside of
the loop.
The testcase has the loop where predecessors outside of the
loop were not identified as analyzeBranch() was unable to
process the mask branch and returned true. That is also not
correct to assert for the truly dead loops.
Differential Revision: https://reviews.llvm.org/D67634
llvm-svn: 372405
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 52621307bcab2013e8833f3317cebd63a6db3885.
Tests have been failing all night with
[0/2] ACTION //llvm/test:check-llvm(//llvm/utils/gn/build/toolchain:unix)
-- Testing: 33647 tests, 64 threads --
Testing: 0 .. 10..
UNRESOLVED: LLVM :: CodeGen/AMDGPU/GlobalISel/isel-blendi-gettargetconstant.ll (6943 of 33647)
******************** TEST 'LLVM :: CodeGen/AMDGPU/GlobalISel/isel-blendi-gettargetconstant.ll' FAILED ********************
Test has no run line!
********************
Since there were other concerns on https://reviews.llvm.org/D67785,
I'm just reverting for now.
llvm-svn: 372383
|