This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
CPol and CPol_GLC1 operand classes have identical predicates, which
means AsmParser cannot differentiate between the RTN and non-RTN
variants of the instructions. When it currently selects the wrong
instruction, a hack in cvtSMEMAtomic() corrects the op-code. Using the
new predicated-value operands makes this hack and the whole conversion
function not needed.
Other uses of CPol_GLC1 operands are to be addressed separately.
Resolves about half of the remaining ~1000 pairs of ambiguous
instructions.
Part of <https://github.com/llvm/llvm-project/issues/69256>.
- Be explicit about which program resource register is supported by
which target
- RSRC1
- FP16_OVFL is GFX9+
- WGP_MODE is GFX10+
- MEM_ORDERED is GFX10+
- FWD_PROGRESS is GFX10+
- RSRC3
- INST_PREF_SIZE is GFX11+
- TRAP_ON_START is GFX11+
- TRAP_ON_END is GFX11+
- IMAGE_OP is GFX11+
- Do not emit GFX11+ fields when disassembling GFX10 code objects
- Tighten enforcement of reserved bits in disassembler
---------
Co-authored-by: Konstantin Zhuravlyov <kzhuravl@amd.com>
A 64-bit literal can be used as a 32-bit zero or sign extended operand.
In case of double zeroes are added to the low 32 bits. Currently asm
parser stores only high 32 bits of a double into an operand. To support
codegen as requested by the
https://github.com/llvm/llvm-project/issues/67781 we need to change the
representation to store a full 64-bit value so that codegen can simply
add immediates to an instruction.
There is some code to support compatibility with existing tests and asm
kernels. We allow to use short hex strings to represent only a high 32
bit of a double value as a valid literal.
A literal can be optionally wrapped in a lit() expression. This does not
force literal encoding for an inline immediate, but neither does SP3.
The syntax is dummy for compatibility only.
In order to avoid duplicating every dpp pseudo opcode that has src1, we
allow it for all opcodes and add manual checks on subtargets that do not
support it.
Code Object V2 has been deprecated for more than a year now. We can
safely remove it from LLVM.
- [clang] Remove support for the `-mcode-object-version=2` option.
- [lld] Remove/refactor tests that were still using COV2
- [llvm] Update AMDGPUUsage.rst
- Code Object V2 docs are left for informational purposes because those
code objects may still be supported by the runtime/loaders for a while.
- [AMDGPU] Remove COV2 emission capabilities.
- [AMDGPU] Remove `MetadataStreamerYamlV2` which was only used by COV2
- [AMDGPU] Update all tests that were still using COV2 - They are either
deleted or ported directly to code object v4 (as v3 is also planned to
be removed soon).
Add assembler directives for preloading kernel arguments that correspond
to new fields in the kernel descriptor for the length and offset of
arguments that will be placed in SGPRs prior to kernel launch. Alignment
of the arguments in SGPRs is equivalent to the kernarg segment when
accessed via the kernarg_segment_ptr. Kernarg SGPRs are allocated
directly after other user SGPRs.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D159459
For the AMD GFX90A GPU, the SCC instruction modifier is allowed for
certain classes of instructions. However, the current assembler
generates an error message, "scc is not supported on this GPU",
regardless of the instruciton. This fix modifies the message as well as
the logic for generating the message. Related tests are moved from
gfx90a_err.s to gfx90a_asm_features.s.
Co-authored-by: Jun Wang <jun.wang7@amd.com>
This finishes the work of replacing OperandMatchResultTy with
ParseStatus, started in D154101.
As a drive-by change, rename some RegNo variables to just Reg
(a leftover from the days when RegNo had 'unsigned' type).
Names '64BitDPP' and especially 'DPP64' were found misleading, and
DPP64 can easily be mixed with DPP16 and DPP8 while these are
different concepts. DPP16 and DPP8 refers to lanes where DPP64
refers to the operand size.
In fact the essential part here is that these instructions are
executed on the DP ALU, so rename the feature accordingly.
I have also found a bug in a check for these instructions, which is
fixed here and a common utility function is now used.
Differential Revision: https://reviews.llvm.org/D158465
GFX90A DS instructions cannot use the gds modifier, except for the
DS_GWS_* instructions where it is still mandatory.
Differential Revision: https://reviews.llvm.org/D157100
* Relax the AsmParser to accept `.amdhsa_wavefront_size32 0` when the
`.amdhsa_shared_vgpr_count` directive is present.
* Teach the KD disassembler to respect the setting of
KERNEL_CODE_PROPERTY_ENABLE_WAVEFRONT_SIZE32 when calculating the
value of `.amdhsa_next_free_vgpr`.
* Teach the KD disassembler to disassemble COMPUTE_PGM_RSRC3 for gfx90a
and gfx10+.
* Include "pseudo directive" comments for gfx10 fields which are not
controlled by any assembler directive.
* Fix disassembleObject failure diagnostic in llvm-objdump to not
hard-code a comment string, and to follow the convention of not
capitalizing the first sentence.
Reviewed By: rochauha
Differential Revision: https://reviews.llvm.org/D128014
ParseStatus is slightly more convenient to use due to implicit
conversion from bool, which allows to do something like:
```
return Error(L, "msg");
```
when with MatchOperandResultTy it had to be:
```
Error(L, "msg");
return MatchOperand_ParseFail;
```
It also has more appropriate name since parse* methods are not only for
parsing operands.
Reviewed By: kosarev
Differential Revision: https://reviews.llvm.org/D154293
Now that we have proper support for optional operands, the standard LLVM
machinery can take care of converting parsed instructions to MCInsts.
There are likely more cases where the conversion can be done
automatically, probably with some additional treatment. The plan is to
address them separately.
Part of <https://github.com/llvm/llvm-project/issues/62629>.
Reviewed By: arsenm, foad
Differential Revision: https://reviews.llvm.org/D153565
Removes the need to add and remove them manually depending on whether
they are used in cvt*() functions. Also removes the compiler warnings
about unused handlers when it happens to be the case.
Part of <https://github.com/llvm/llvm-project/issues/62629>.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D151688
At the moment, we set the BC bit in DPP for both bound_ctrl:0 and
bound_ctrl:1, for compatibility with sp3 (see PR35397). However, this
hack is only needed for GFX8. For newer GFXs, sp3 behaves as expected,
i.e. it sets the bit when bound_ctrl:1 and clears it when bound_ctrl:0.
This patch updates LLVM to do the same for GFX11 or newer. We preserve
the current behaviour for GFX9 and 10 so we don't break any existing
code.
Differential Revision: https://reviews.llvm.org/D149254
This is rework of;
- rG13e77db2df94 (r328395; MVT)
Since `LowLevelType.h` has been restored to `CodeGen`, `MachinveValueType.h`
can be restored as well.
Depends on D148767
Differential Revision: https://reviews.llvm.org/D149024
Fixes the following building errors, happening with official Android prebuilt clang 14 shipped with Android 13:
external/llvm-project/llvm/lib/Target/AMDGPU/AsmParser/AMDGPUAsmParser.cpp:5491:13: error: no viable constructor or deduction guide for deduction of template arguments of 'tuple'
? std::tuple(HSAMD::V3::AssemblerDirectiveBegin,
^
...
external/llvm-project/llvm/lib/Target/AMDGPU/AsmParser/AMDGPUAsmParser.cpp:5493:13: error: no viable constructor or deduction guide for deduction of template arguments of 'tuple'
: std::tuple(HSAMD::AssemblerDirectiveBegin,
^
Fixes: 6443c0e ("[AMDGPU] Stop using make_pair and make_tuple. NFC.")
Patch by Mauro Rossi!
Differential Revision: https://reviews.llvm.org/D142839
- Fixes the type of default 8-bit offset operands.
- Adds a test for optional offsets.
This is effectively an NFC.
Reviewed By: dp
Differential Revision: https://reviews.llvm.org/D142231
