| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This was only applying the deeper nested zext pattern, and missing the
special case code size fold.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are duplicating predicates if several parts of the combined
predicate list contain the same condition. Added code to deduplicate
the list.
We have AssemblerPredicates and AssemblerPredicate in the
PredicateControl, but we never use AssemblerPredicates with an
actual list, so this one is dropped.
This addresses the first part of the llvm bug 43886:
https://bugs.llvm.org/show_bug.cgi?id=43886
Differential Revision: https://reviews.llvm.org/D69815
|
|
|
|
|
|
|
|
|
|
| |
See https://bugs.llvm.org/show_bug.cgi?id=43608
Reviewers: arsenm, rampitec
Differential Revision: https://reviews.llvm.org/D69096
llvm-svn: 375241
|
|
|
|
|
|
|
|
|
|
| |
See https://bugs.llvm.org/show_bug.cgi?id=43607
Reviewers: arsenm, rampitec
Differential Revision: https://reviews.llvm.org/D69095
llvm-svn: 375231
|
|
|
|
|
|
|
|
|
| |
Do not generate non-existing sdwa instructions. It reduces the
number of generated instructions by 185.
Differential Revision: https://reviews.llvm.org/D69010
llvm-svn: 375016
|
|
|
|
|
|
|
|
|
|
|
|
| |
This defaults to zero fi operand, but we do not expose it
anyway. Should we expose it later it needs to be added to
the pseudo.
This enables dpp combining on gfx10.
Differential Revision: https://reviews.llvm.org/D68888
llvm-svn: 374604
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were 2 problems here. First, these patterns were duplicated to
handle the inverted shift operands instead of using the commuted
PatFrags.
Second, the point of the zext folding patterns don't apply to the
non-0ing high subtargets. They should be skipped instead of inserting
the extension. The zeroing high code would be emitted when necessary
anyway. This was also emitting unnecessary zexts in cases where the
high bits were undefined.
llvm-svn: 374092
|
|
|
|
|
|
|
|
|
|
|
| |
Inhibit generation of unused real dpp instructions on gfx10 just
like it is done on other subtargets. This does not change anything
because these are illegal anyway and not accepted, but it does
reduce the number of instruction definitions generated.
Differential Revision: https://reviews.llvm.org/D68607
llvm-svn: 374083
|
|
|
|
| |
llvm-svn: 373945
|
|
|
|
| |
llvm-svn: 373180
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 371807
|
|
|
|
| |
llvm-svn: 371798
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 366257
|
|
|
|
| |
llvm-svn: 366256
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 366254
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D64431
llvm-svn: 365715
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D64433
llvm-svn: 365573
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D63204
llvm-svn: 363934
|
|
|
|
|
|
|
|
|
| |
This is part of the approved D63204 pending parent revision.
This small change is in fact a part of the VOP2b legalization which
does not technically belong to wave32 support, so extracted
separately.
llvm-svn: 363625
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D63307
llvm-svn: 363344
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D63293
llvm-svn: 363299
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D63203
llvm-svn: 363186
|
|
|
|
|
|
|
|
| |
Reviewers: rampitec, arsenm
Differential Revision: https://reviews.llvm.org/D61905
llvm-svn: 360702
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The VOP3 form should always be the preferred selection, to be shrunk
later. This should only be an optimization issue, but this partially
works around a problem from clobbering VCC when SIFixSGPRCopies
rewrites an SCC defining operation directly to VCC.
3 of the testcases are regressions from failing to fold the immediate
in cases it should. These can be avoided by improving the VCC liveness
handling in SIFoldOperands. Simply increasing the threshold to
computeRegisterLiveness works, although this is common enough that VCC
liveness should probably be tracked throughout the pass. The hack of
leaving behind an implicit_def instruction to avoid breaking iterator
wastes instruction count, which inhibits finding the VCC def in long
chains of adds. Doing this however exposes different, worse looking
regressions from poor scheduling behavior. This could probably be
avoided around by forcing the shrink of the addc here, but the
scheduler should probably be fixed.
The r600 add test needs to be split out because it asserts on the
arguments in the new test during the calling convention lowering.
llvm-svn: 360293
|
|
|
|
|
|
|
| |
Differential Revision:
https://reviews.llvm.org/D61430
llvm-svn: 360283
|
|
|
|
|
|
|
|
|
|
| |
The VOP3 form should always be the preferred selection form to be
shrunk later.
The r600 sub test needs to be split out because it asserts on the
arguments in the new test during the calling convention lowering.
llvm-svn: 359899
|
|
|
|
| |
llvm-svn: 359895
|
|
|
|
|
|
|
| |
There were 2 patterns for sub, one selecting to sub and one to
subrev. Only one of these will succeed, so remove the reversed one.
llvm-svn: 359894
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D61208
llvm-svn: 359358
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D61156
llvm-svn: 359316
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D61099
llvm-svn: 359225
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D60346
llvm-svn: 357835
|
|
|
|
|
|
|
|
|
| |
We have done some predicate and feature refactoring lately but
did not upstream it. This is to sync.
Differential revision: https://reviews.llvm.org/D60292
llvm-svn: 357791
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow the clamp modifier on vop3 int arithmetic instructions in assembly
and disassembly.
This involved adding a clamp operand to the affected instructions in MIR
and MC, and thus having to fix up several places in codegen and MIR
tests.
Differential Revision: https://reviews.llvm.org/D59267
Change-Id: Ic7775105f02a985b668fa658a0cd7837846a534e
llvm-svn: 356399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit allows v_cndmask_b32_e64 with abs, neg source
modifiers on src0, src1 to be assembled and disassembled.
This does appear to be allowed, even though they are floating point
modifiers and the operand type is b32.
To do this, I added src0_modifiers and src1_modifiers to the
MachineInstr, which involved fixing up several places in codegen and mir
tests.
Differential Revision: https://reviews.llvm.org/D59191
Change-Id: I69bf4a8c73ebc65744f6110bb8fc4e937d79fbea
llvm-svn: 356398
|
|
|
|
|
|
|
|
|
|
|
|
| |
v_readlane_b32 and v_writelane_b32
See bug 40662: https://bugs.llvm.org/show_bug.cgi?id=40662
Reviewers: artem.tamazov, arsenm, rampitec
Differential Revision: https://reviews.llvm.org/D58713
llvm-svn: 355312
|
|
|
|
|
|
|
| |
It breaks one of our downstream merges, so revert it
temporarily while investigating failures downstream
llvm-svn: 354700
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D58522
llvm-svn: 354620
|
|
|
|
|
|
|
| |
These are no longer necessary since the R600 tablegen files are split
out now.
llvm-svn: 353548
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A new pass to manage the Mode register.
Currently this just manages the floating point double precision
rounding requirements, but is intended to be easily extended to
encompass all Mode register settings.
The immediate motivation comes from the requirement to use the
round-to-zero rounding mode for the 16 bit interpolation
instructions, where the rounding mode setting is shared between
16 and 64 bit operations.
llvm-svn: 348754
|
|
|
|
|
|
|
|
| |
Introduces DPP pseudo instructions and the pass that combines DPP mov with subsequent uses.
Differential revision: https://reviews.llvm.org/D53762
llvm-svn: 347993
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce new versions that follow the IEEE semantics
to help with legalization that may need quieted inputs.
There are some regressions from inserting unnecessary
canonicalizes when these are matched from fast math
fcmp + select which should be fixed in a future commit.
llvm-svn: 344914
|
|
|
|
| |
llvm-svn: 343264
|