These instructions have non-standard use of OPSEL bits to select
dest write byte. The src2_modifiers operand is used without having
its corresponding src2 operand by introducing dummy src2.
Co-authored-by: Pravin Jagtap <Pravin.Jagtap@amd.com>
Unlike with implicitly preloaded data UserSGPRs firmware is unable to
handle cases where SGPRs for kernel arguments contain preloaded data but
not are not explicitly referenced in the kernel. We need to include
these preloaded SGPRs in the GRANULATED_WAVEFRONT_SGPR_COUNT calculation
to not clobber SGPRs in adjacent waves.
Don't call raw_string_ostream::flush(), which is essentially a no-op.
As specified in the docs, raw_string_ostream is always unbuffered.
( 65b13610a5226b84889b923bae884ba395ad084d for further reference )
This is a large patch includes the MC level support for V_CVT_F16_F32,
V_CVT_F32_F16 and V_LDEXP_F16 in true16 format.
This patch includes the asm/disasm changes to encode/decode the 16bit
vsrc, vdst and src modifieres for vop and dpp format. This patch is a
dependency for many 16 bit instructions while only three instructions
are updated to make it easier to review.
There will be another patch to support these three instructions in the
codeGen level, this patch just replaces these two instructions with its
fake16 format.
And declare it to take an MCRegister.
Also rename related entities and remove a comment for the function that
depending on its purpose is either irrelevant or misleading.
Mention the names of unavailable registers in error messages to not make
the diagnostics for execz/vccz less rich than it was.
Clean up unnecessary name qualifications while there.
Part of <https://github.com/llvm/llvm-project/issues/62629>.
The work of ParseRegularReg() should remain to be parsing the register
as it was specified, and not to try translate it to anything else.
It's up to operand predicates to decide on what is and is not an
acceptable register for an operand, including considering its expected
register class, and for the rest of the AsmParser infrastructure to
handle it respectively from there on.
When we have a modifier with a value (like dst_sel:DWORD for example) we
only accept symbolic values. SP3 allows to use numberic constants as
well. Adding a helper function to allow both.
Besides the compatibility it is easier to use.
For GFX10+, the MIMG instrucitons generally require a dim operand.
However, when dim is missing, the assembler produces the error message
"operands are not valid for this GPU or mode" (See issue
https://github.com/llvm/llvm-project/issues/47585). This patch fixes the
issue by producing a more direct error message.
---------
Co-authored-by: Jun Wang <jun.wang7@amd.com>
An appropriately configured image resource descriptor can trigger
image_sample instructions to store outputs directly to a linked memory
location instead of returning to VGPRs.
This is opaque to the backend as instruction encoding is unchanged;
however, a mechanism is require to allow frontends to communicate that
these instructions do not require destination VGPRs and store to memory.
Flagging these as stores means they will not be optimized away.
Processor definition shall not include a default feature which may be
switched off by a different wave size. This allows not to write
-mattr=-wavefrontsize32,+wavefrontsize64 in tests.
Some of our custom expressions are not variadic and there seems to be
little benefit in mentioning the variadic nature of expression nodes in
the name anyway.
This is no longer supported as of gfx9. Fixes#52903
This commit also includes some refactoring of sendmsg operand parsing:
- Use CustomOperand for sendmsg operations, this allows them to be
conditionally available based on a STI check (and automatically in
sync with SIDefines.h).
- Move CustomOperand table lookups from AMDGPUBaseInfo to
AMDGPUAsmUtils. This cleans up an awkward interface where
AMDGPUAsmUtils defined a table/size as globals that AMDGPUBaseInfo
had to loop over.
- Clean up a few of the operand lookup functions while moving them.
Their job is to discriminate between different types of operands, not to
check if they are valid. For validation we can use conversion functions.
Clears the road to generating predicates automatically.
Part of <https://github.com/llvm/llvm-project/issues/62629>.
…ng VOPC.
Fixes support on GFX1150 and GFX12 where src1 of e64_dpp instructions
should allow sgpr and imm operands.
PR #67461 added support for this with int operands, but it was missing a
piece for float.
Changing VOPC e64_dpp will be in a different patch because there is a
bug preventing that change.
The current implementation of `isInlinableLiteral16` assumes, a 16-bit
inlinable
literal is either an `i16` or a `fp16`. This is not always true because
of
`bf16`. However, we can't tell `fp16` and `bf16` apart by just looking
at the
value. This patch splits `isInlinableLiteral16` into three versions,
`i16`,
`fp16`, `bf16` respectively, and call the corresponding version.
Rename getNumVGPRBlocks to getEncodedNumVGPRBlocks, to clarify that it's
using the encoding granule. This is used to program the hardware. In
practice, the hardware will use the alloc granule instead, so this patch
also adds a new helper, getAllocatedNumVGPRBlocks, which can be useful
when driving heuristics.
