I think this manages to not break the DAG handling with the divergent
predicates because the stadalone divergent patterns end up with a
higher priority than the pattern on the instruction definition.
The 16-bit versions don't work yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366254 91177308-0d34-0410-b5e6-96231b3b80d8
For some reason GlobalISelEmitter needs register classes to import
these, although it works for the load patterns.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366242 91177308-0d34-0410-b5e6-96231b3b80d8
Now that the patterns use the new PatFrag address space support, the
only blocker to importing most load patterns is the addressing mode
complex patterns.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366237 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Extend the atomic optimizer to handle signed and unsigned max and min
operations, as well as add and subtract.
Reviewers: arsenm, sheredom, critson, rampitec
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64328
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366235 91177308-0d34-0410-b5e6-96231b3b80d8
Rewrite PatFrags using the new PatFrag address space matching in
tablegen. These will now work with both SelectionDAG and GlobalISel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366234 91177308-0d34-0410-b5e6-96231b3b80d8
Apparently the check for legal instructions during instruction
select does not happen without an asserts build, so these would
successfully select in release, and fail in debug.
Make s16 and/or/xor legal. These can just be selected directly
to the 32-bit operation, as is already done in SelectionDAG, so just
make them legal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366210 91177308-0d34-0410-b5e6-96231b3b80d8
Use the MemoryVT field. This will be necessary for tablegen to
automatically handle patterns for GlobalISel.
Doesn't handle the d16 lo/hi patterns. Those are a special case since
it involvess the custom node type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366168 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Enable hoisting and merging m0 defs that are initialized with the same
immediate value. Fixes bug where removed instructions are not considered
to interfere with other inits, and make sure to not hoist inits before block
prologues.
Reviewers: rampitec, arsenm
Reviewed By: rampitec
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64766
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366135 91177308-0d34-0410-b5e6-96231b3b80d8
We already do this for the flat and DS instructions, although it is
certainly uglier and more verbose.
This will allow using separate pattern definitions for extload and
zextload. Currently we get away with using a single PatFrag with
custom predicate code to check if the extension type is a zextload or
anyextload. The generic mechanism the global isel emitter understands
treats these as mutually exclusive. I was considering making the
pattern emitter accept zextload or sextload extensions for anyextload
patterns, but in global isel, the different extending loads have
distinct opcodes, and there is currently no mechanism for an opcode
matcher to try multiple (and there probably is very little need for
one beyond this case).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366132 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366125 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366120 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366119 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366094 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365953 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365910 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365904 91177308-0d34-0410-b5e6-96231b3b80d8
