| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
For AMDGPU the result is always 32-bit for 64-bit inputs.
llvm-svn: 352717
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is meant to be used with clang's __builtin_dynamic_object_size.
When 'true' is passed to this parameter, the intrinsic has the
potential to be folded into instructions that will be evaluated
at run time. When 'false', the objectsize intrinsic behaviour is
unchanged.
rdar://32212419
Differential revision: https://reviews.llvm.org/D56761
llvm-svn: 352664
|
|
|
|
| |
llvm-svn: 352601
|
|
|
|
| |
llvm-svn: 352599
|
|
|
|
| |
llvm-svn: 352594
|
|
|
|
|
|
| |
Also add some quick hacks to AMDGPU legality for the tests.
llvm-svn: 352591
|
|
|
|
| |
llvm-svn: 352585
|
|
|
|
|
|
|
| |
Not sure if the old AArch64 tests should be just
deleted or not.
llvm-svn: 352562
|
|
|
|
| |
llvm-svn: 352560
|
|
|
|
|
|
|
|
|
|
| |
This was ignoring the memory size, and producing multiple loads/stores
if the operand size was different from the memory size.
I assume this is the intent of not having an explicit G_ANYEXTLOAD
(although I think that would probably be better).
llvm-svn: 352523
|
|
|
|
|
|
|
|
|
|
|
| |
I found a really strange WWM issue through a very convoluted shader that
essentially boils down to a bug in SIInstrInfo where canReadVGPR did not
correctly identify that WWM is like a copy and can have a VGPR as its
source.
Differential Revision: https://reviews.llvm.org/D56002
llvm-svn: 352500
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since these pass the pointer in m0 unlike other DS instructions, these
need to worry about whether the address is uniform or not. This
assumes the address is dynamically uniform, and just uses
readfirstlane to get a copy into an SGPR.
I don't know if these have the same 16-bit add for the addressing mode
offset problem on SI or not, but I've just assumed they do.
Also includes some misc. changes to avoid test differences between the
LDS and GDS versions.
llvm-svn: 352422
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Added the intrinsics llvm.amdgcn.interp.p1.f16() and
llvm.amdgcn.interp.p2.f16() and related LIT test.
The p1 intrinsic generates code appropriate for both 16 and 32
bank LDS.
Reviewers: #amdgpu, dstuttard, arsenm, tpr
Reviewed By: #amdgpu, arsenm
Subscribers: jvesely, mgorny, arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D46754
llvm-svn: 352357
|
|
|
|
|
|
|
| |
This is invalid for the same reason as in the narrowScalar handling
for load.
llvm-svn: 352334
|
|
|
|
|
|
|
| |
I expected this to be automatically verified, but it seems
nothing uses that the type index was declared as a "ptype"
llvm-svn: 352319
|
|
|
|
| |
llvm-svn: 352300
|
|
|
|
| |
llvm-svn: 352298
|
|
|
|
| |
llvm-svn: 352295
|
|
|
|
| |
llvm-svn: 352294
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If bottom of block BB has only one successor OldTop, in most cases it is profitable to move it before OldTop, except the following case:
-->OldTop<-
| . |
| . |
| . |
---Pred |
| |
BB-----
Move BB before OldTop can't reduce the number of taken branches, this patch detects this case and prevent the moving.
Differential Revision: https://reviews.llvm.org/D57067
llvm-svn: 352236
|
|
|
|
| |
llvm-svn: 352167
|
|
|
|
| |
llvm-svn: 352166
|
|
|
|
| |
llvm-svn: 352165
|
|
|
|
| |
llvm-svn: 352162
|
|
|
|
|
|
| |
Also legalize 64-bit compares for AMDGPU
llvm-svn: 352157
|
|
|
|
| |
llvm-svn: 352155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/D57178
Now add a hook in TargetPassConfig to query if CSE needs to be
enabled. By default this hook returns false only for O0 opt level but
this can be overridden by the target.
As a consequence of the default of enabled for non O0, a few tests
needed to be updated to not use CSE (by passing in -O0) to the run
line.
reviewed by: arsenm
llvm-svn: 352126
|
|
|
|
| |
llvm-svn: 352123
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With XNACK, an smem load whose result is coalesced with an operand (thus
it overwrites its own operand) cannot appear in a clause, because some
other instruction might XNACK and restart the whole clause.
The clause breaker already realized that an smem that overwrites an
operand cannot appear in a clause, and broke the clause. The problem
that this commit fixes is that the SIFormMemoryClauses optimization
formed a bundle with early clobber, which caused the earlier code that
set up the coalesced operand to be removed as dead.
Differential Revision: https://reviews.llvm.org/D57008
Change-Id: I703c4d5b0bf7d6060222bec491f45c18bb3c0016
llvm-svn: 351950
|
|
|
|
|
|
|
|
| |
It might be a bit nicer to use the fancy .legalIf and co. predicates,
but this was requiring more boilerplate and disables the coverage
assertions.
llvm-svn: 351886
|
|
|
|
| |
llvm-svn: 351884
|
|
|
|
| |
llvm-svn: 351871
|
|
|
|
| |
llvm-svn: 351866
|
|
|
|
| |
llvm-svn: 351856
|
|
|
|
| |
llvm-svn: 351853
|
|
|
|
| |
llvm-svn: 351851
|
|
|
|
| |
llvm-svn: 351767
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes two problems with GCNHazardRecognizer:
1. It only scans up to 5 instructions emitted earlier.
2. It does not take control flow into account. An earlier instruction
from the previous basic block is not necessarily a predecessor.
At the same time a real predecessor block is not scanned.
The patch provides a way to distinguish between scheduler and
hazard recognizer mode. It is OK to work with emitted instructions
in the scheduler because we do not really know what will be emitted
later and its order. However, when pass works as a hazard recognizer
the schedule is already finalized, and we have full access to the
instructions for the whole function, so we can properly traverse
predecessors and their instructions.
Differential Revision: https://reviews.llvm.org/D56923
llvm-svn: 351759
|
|
|
|
| |
llvm-svn: 351700
|
|
|
|
|
|
|
|
| |
There is a combine that was hiding these tests
not actually testing what they should be, although
they were producing the expected end result.
llvm-svn: 351698
|
|
|
|
| |
llvm-svn: 351696
|
|
|
|
| |
llvm-svn: 351695
|
|
|
|
|
|
|
|
|
|
|
| |
This was crashing in the predicate function assuming the value
is a vector.
Copy more of what AArch64 uses. This probably needs more refinement
later, but I don't exactly understand what it means in some cases,
particularly since any legalization for these seems to be missing.
llvm-svn: 351693
|
|
|
|
| |
llvm-svn: 351692
|
|
|
|
| |
llvm-svn: 351691
|
|
|
|
| |
llvm-svn: 351599
|
|
|
|
| |
llvm-svn: 351596
|
|
|
|
|
|
|
|
|
|
| |
See bug 39332: https://bugs.llvm.org/show_bug.cgi?id=39332
Reviewers: artem.tamazov, arsenm
Differential Revision: https://reviews.llvm.org/D56794
llvm-svn: 351555
|
|
|
|
| |
llvm-svn: 351494
|
|
|
|
| |
llvm-svn: 351427
|