| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Custom lower this to a target instruction with the merge operands. I
think it might be better to directly select this and emit a
REG_SEQUENCE, but this would be more work since it would require
splitting the tablegen patterns for these cases from the other
atomics.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Reviewed By: arsenm
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, rovka, dstuttard, tpr, t-tye, hiraditya, volkan, Petar.Avramovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69347
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/D69231
llvm-svn: 375460
|
| |
|
|
|
|
|
| |
Port directly from SelectionDAG, minus the path using
ISD::SADDSAT/ISD::SSUBSAT.
llvm-svn: 375042
|
| |
|
|
|
|
| |
Turn it into a G_CONCAT_VECTORS of G_BUILD_VECTOR.
llvm-svn: 374252
|
| |
|
|
| |
llvm-svn: 373989
|
| |
|
|
| |
llvm-svn: 373946
|
| |
|
|
|
|
| |
Continue making a mess of merge/unmerge legality.
llvm-svn: 373942
|
| |
|
|
| |
llvm-svn: 373839
|
| |
|
|
|
|
| |
Turn into shift and truncate. Doesn't yet handle pointers.
llvm-svn: 373838
|
| |
|
|
|
|
|
| |
This was always passing the destination flat address space, when it
should be picking between the two valid source options.
llvm-svn: 373716
|
| |
|
|
|
|
| |
This would try to do FewerElements to v9s8
llvm-svn: 373635
|
| |
|
|
| |
llvm-svn: 373567
|
| |
|
|
| |
llvm-svn: 373417
|
| |
|
|
|
|
| |
This will be needed to support AGPR operations.
llvm-svn: 373413
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 373298
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
This reverts r372314, reapplying r372285 and the commits which depend
on it (r372286-r372293, and r372296-r372297)
This was missing one switch to getTargetConstant in an untested case.
llvm-svn: 372338
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This broke the Chromium build, causing it to fail with e.g.
fatal error: error in backend: Cannot select: t362: v4i32 = X86ISD::VSHLI t392, Constant:i8<15>
See llvm-commits thread of r372285 for details.
This also reverts r372286, r372287, r372288, r372289, r372290, r372291,
r372292, r372293, r372296, and r372297, which seemed to depend on the
main commit.
> Encode them directly as an imm argument to G_INTRINSIC*.
>
> Since now intrinsics can now define what parameters are required to be
> immediates, avoid using registers for them. Intrinsics could
> potentially want a constant that isn't a legal register type. Also,
> since G_CONSTANT is subject to CSE and legalization, transforms could
> potentially obscure the value (and create extra work for the
> selector). The register bank of a G_CONSTANT is also meaningful, so
> this could throw off future folding and legalization logic for AMDGPU.
>
> This will be much more convenient to work with than needing to call
> getConstantVRegVal and checking if it may have failed for every
> constant intrinsic parameter. AMDGPU has quite a lot of intrinsics wth
> immarg operands, many of which need inspection during lowering. Having
> to find the value in a register is going to add a lot of boilerplate
> and waste compile time.
>
> SelectionDAG has always provided TargetConstant for constants which
> should not be legalized or materialized in a register. The distinction
> between Constant and TargetConstant was somewhat fuzzy, and there was
> no automatic way to force usage of TargetConstant for certain
> intrinsic parameters. They were both ultimately ConstantSDNode, and it
> was inconsistently used. It was quite easy to mis-select an
> instruction requiring an immediate. For SelectionDAG, start emitting
> TargetConstant for these arguments, and using timm to match them.
>
> Most of the work here is to cleanup target handling of constants. Some
> targets process intrinsics through intermediate custom nodes, which
> need to preserve TargetConstant usage to match the intrinsic
> expectation. Pattern inputs now need to distinguish whether a constant
> is merely compatible with an operand or whether it is mandatory.
>
> The GlobalISelEmitter needs to treat timm as a special case of a leaf
> node, simlar to MachineBasicBlock operands. This should also enable
> handling of patterns for some G_* instructions with immediates, like
> G_FENCE or G_EXTRACT.
>
> This does include a workaround for a crash in GlobalISelEmitter when
> ARM tries to uses "imm" in an output with a "timm" pattern source.
llvm-svn: 372314
|
| |
|
|
|
|
|
|
|
| |
This needs special handling due to some subtargets that have a
nonstandard register layout for f16 vectors
Also reject some illegal types on other targets.
llvm-svn: 372293
|
| |
|
|
| |
llvm-svn: 372292
|
| |
|
|
| |
llvm-svn: 371952
|
| |
|
|
| |
llvm-svn: 371950
|
| |
|
|
| |
llvm-svn: 371811
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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: 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
|
| |
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 371412
|
| |
|
|
| |
llvm-svn: 371407
|
| |
|
|
|
|
|
| |
The library currently uses ptrtoint and directly checks the queue ptr
for this, which counts as a pointer capture.
llvm-svn: 371009
|
| |
|
|
|
|
| |
Avoids SSA violations in a future patch.
llvm-svn: 371008
|
| |
|
|
| |
llvm-svn: 371007
|
| |
|
|
| |
llvm-svn: 370979
|
| |
|
|
|
|
| |
This is mostly for the benefit of patterns which use 16-bit constants.
llvm-svn: 370921
|
| |
|
|
| |
llvm-svn: 370405
|
| |
|
|
| |
llvm-svn: 370402
|
| |
|
|
| |
llvm-svn: 370140
|
| |
|
|
|
|
|
|
| |
This is necessary for handling <3 x s16> on AMDGPU, assuming this
should be handled as 2 separate legalization actions. The alternative
would be for fewerElementsVector to handle 3->2.
llvm-svn: 369547
|