| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: arsenm, sdardis, nemanjai, jvesely, nhaehnle, hiraditya, kbarton, jrtc27, MaskRay, atanasyan, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67620
llvm-svn: 372231
|
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D67680
Change-Id: Ic38f47cb2079c2c1070a441b5943854844d80a7c
llvm-svn: 372208
|
|
|
|
|
|
|
|
| |
NFC, needed for future commit.
Differential Revision: https://reviews.llvm.org/D67669
llvm-svn: 372151
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Reordered MVT simple types to group scalable vector types
together.
* New range functions in MachineValueType.h to only iterate over
the fixed-length int/fp vector types.
* Stopped backends which don't support scalable vector types from
iterating over scalable types.
Reviewers: sdesmalen, greened
Reviewed By: greened
Differential Revision: https://reviews.llvm.org/D66339
llvm-svn: 372099
|
|
|
|
|
|
|
| |
Defferential Revision: https://reviews.llvm.org/D67101
Reviewers: rampitec, vpykhtin
llvm-svn: 372086
|
|
|
|
|
|
|
| |
This was producing an illegal copy which would hit an assert
later. Error on selection for now until this is implemented.
llvm-svn: 371993
|
|
|
|
| |
llvm-svn: 371991
|
|
|
|
| |
llvm-svn: 371954
|
|
|
|
| |
llvm-svn: 371953
|
|
|
|
| |
llvm-svn: 371952
|
|
|
|
|
|
|
| |
Fixes assertion with workitem ID intrinsics used in non-kernel
functions.
llvm-svn: 371951
|
|
|
|
| |
llvm-svn: 371950
|
|
|
|
| |
llvm-svn: 371949
|
|
|
|
| |
llvm-svn: 371948
|
|
|
|
| |
llvm-svn: 371873
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet, JDevlieghere
Subscribers: arsenm, sdardis, jvesely, nhaehnle, sbc100, hiraditya, aheejin, jrtc27, atanasyan, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67486
llvm-svn: 371831
|
|
|
|
|
|
| |
llvm.amdgcn.else hits this.
llvm-svn: 371812
|
|
|
|
| |
llvm-svn: 371811
|
|
|
|
| |
llvm-svn: 371808
|
|
|
|
| |
llvm-svn: 371807
|
|
|
|
| |
llvm-svn: 371803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike SelectionDAG, treat this as a normally legalizable operation.
In SelectionDAG this is supposed to only ever formed if it's legal,
but I've found that to be restricting. For AMDGPU this is contextually
legal depending on whether denormal flushing is allowed in the use
function.
Technically we currently treat the denormal mode as a subtarget
feature, so custom lowering could be avoided. However I consider this
to be a defect, and this should be contextually dependent on the
controllable rounding mode of the parent function.
llvm-svn: 371800
|
|
|
|
| |
llvm-svn: 371798
|
|
|
|
|
|
|
|
| |
The result integer does not need to be the same width as the input.
AMDGPU, NVPTX, and Hexagon all have patterns working around the types
matching. GlobalISel defines these as being different type indexes.
llvm-svn: 371797
|
|
|
|
|
|
|
|
|
| |
This was relying on the SGPR usable for the carry out clobber to also
be used for the input. There was no carry out on gfx9. With no carry
out clobber to worry about, so the literal can just be directly used
with a VOP2 add.
llvm-svn: 371791
|
|
|
|
| |
llvm-svn: 371761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
After hoisting and merging m0 initializations schedule them as early as
possible in the MBB. This helps the scheduler avoid hazards in some
cases.
Reviewers: rampitec, arsenm
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67450
llvm-svn: 371671
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: - Pre-check in case there's just a single PHI insn.
Reviewers: alex-t, rampitec, arsenm
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, dstuttard, tpr, t-tye, hiraditya, llvm-commits, yaxunl
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67451
llvm-svn: 371649
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mir parsing
Summary:
This catches malformed mir files which specify alignment as log2 instead of pow2.
See https://reviews.llvm.org/D65945 for reference,
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: MatzeB, qcolombet, dschuff, arsenm, sdardis, nemanjai, jvesely, nhaehnle, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, s.egerton, pzheng, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67433
llvm-svn: 371608
|
|
|
|
|
|
|
|
| |
The scalar f64 patterns don't work yet because they fail on multiple
results from the unused implicit def of scc in the result bit
operation.
llvm-svn: 371542
|
|
|
|
|
|
|
|
|
|
|
| |
f64 doesn't work yet because tablegen currently doesn't handlde
REG_SEQUENCE.
This does regress some multi use VALU fneg cases since now the
immediate remains in an SGPR, and more moves are used for legalizing
the xor. This is a SIFixSGPRCopies deficiency.
llvm-svn: 371540
|
|
|
|
| |
llvm-svn: 371539
|
|
|
|
| |
llvm-svn: 371538
|
|
|
|
| |
llvm-svn: 371536
|
|
|
|
|
|
|
| |
Legalize by casting to a 64-bit constant address. This isn't how the
DAG implements it, but it should.
llvm-svn: 371535
|
|
|
|
|
|
|
|
| |
There's still a lot more to do, but this handles decomposing due to
alignment. I've gotten it to the point where nothing crashes or
infinite loops the legalizer.
llvm-svn: 371533
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Reviewed By: courbet
Subscribers: wuzish, arsenm, nemanjai, jvesely, nhaehnle, hiraditya, kbarton, MaskRay, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67386
llvm-svn: 371511
|
|
|
|
|
|
|
|
| |
Reviewers: rampitec, vpykhtin
Differential Revision: https://reviews.llvm.org/D67101
llvm-svn: 371508
|
|
|
|
| |
llvm-svn: 371471
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Reviewed By: arsenm
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, rovka, dstuttard, tpr, t-tye, hiraditya, Petar.Avramovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67374
llvm-svn: 371467
|
|
|
|
|
|
|
|
| |
Handle it the same way as G_BUILD_VECTOR_TRUNC. Arguably only
G_BUILD_VECTOR_TRUNC should be legal for this, but G_BUILD_VECTOR will
probably be more convenient in most cases.
llvm-svn: 371440
|
|
|
|
|
|
|
| |
This was getting chosen as the preferred 32-bit register class based
on how TableGen selects subregister classes.
llvm-svn: 371438
|
|
|
|
|
|
| |
Also fixes missing SubtargetPredicate on f16 class instructions.
llvm-svn: 371436
|
|
|
|
| |
llvm-svn: 371435
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enables GlobalISel to handle various intrinsics. The custom node
pattern will be ignored, and the intrinsic will work. This will also
allow SelectionDAG to directly select the intrinsics, but as they are
all custom lowered to the nodes, this ends up leaving dead code in the
table.
Eventually either GlobalISel should add the equivalent of custom nodes
equivalent, or intrinsics should be directly used. These each have
different tradeoffs.
There are a few more to handle, but these are easy to handle
ones. Some others fail for other reasons.
llvm-svn: 371432
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately MnemonicAlias defines a "Predicates" field just like an
instruction or pattern, with a somewhat different interpretation.
This ends up overriding the intended Predicates set by
PredicateControl on the pseudoinstruction defintions with an empty
list. This allowed incorrectly selecting instructions that should have
been rejected due to the SubtargetPredicate from patterns on the
instruction definition.
This does remove the divergent predicate from the 64-bit shift
patterns, which were already not used for the 32-bit shift, so I'm not
sure what the point was. This also removes a second, redundant copy of
the 64-bit divergent patterns.
llvm-svn: 371427
|
|
|
|
|
|
| |
Handle the simple case that lowers to a constant.
llvm-svn: 371424
|
|
|
|
|
|
|
|
|
|
| |
Treat this as legal on gfx9 since it can use S_PACK_* instructions for
this.
This isn't used by anything yet. The same will probably apply to
16-bit G_BUILD_VECTOR without the trunc.
llvm-svn: 371423
|
|
|
|
|
|
|
| |
A new check for an explicitly atomic MMO is needed to avoid
incorrectly matching pattern for non-atomic loads
llvm-svn: 371418
|
|
|
|
| |
llvm-svn: 371416
|