https://gcc.gnu.org/g:6dedafe166cc02ae87b6a0699ad61ce3ffc46803
commit r14-9626-g6dedafe166cc02ae87b6a0699ad61ce3ffc46803
Author: Andrew Stubbs <a...@baylibre.com>
Date: Thu Feb 22 11:41:19 2024 +0000
amdgcn: Prefer V32 on RDNA devices
We run these devices in wavefrontsize64 for compatibility, but they actually
only have 32-lane vectors, natively. If the upper part of a V64 is masked
off (as it is in V32) then RDNA devices will skip execution of the upper
part
for most operations, so this adjustment shouldn't leave too much
performance on
the table. One exception is memory instructions, so full wavefrontsize32
support would be better.
The advantage is that we avoid the missing V64 operations (such as permute
and
vec_extract).
gcc/ChangeLog:
* config/gcn/gcn.cc (gcn_vectorize_preferred_simd_mode): Prefer V32
on
RDNA devices.
Diff:
---
gcc/config/gcn/gcn.cc | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/gcc/config/gcn/gcn.cc b/gcc/config/gcn/gcn.cc
index 498146dcde9..efb73af50c4 100644
--- a/gcc/config/gcn/gcn.cc
+++ b/gcc/config/gcn/gcn.cc
@@ -5226,6 +5226,32 @@ gcn_vector_mode_supported_p (machine_mode mode)
static machine_mode
gcn_vectorize_preferred_simd_mode (scalar_mode mode)
{
+ /* RDNA devices have 32-lane vectors with limited support for 64-bit vectors
+ (in particular, permute operations are only available for cases that don't
+ span the 32-lane boundary).
+
+ From the RDNA3 manual: "Hardware may choose to skip either half if the
+ EXEC mask for that half is all zeros...". This means that preferring
+ 32-lanes is a good stop-gap until we have proper wave32 support. */
+ if (TARGET_RDNA2_PLUS)
+ switch (mode)
+ {
+ case E_QImode:
+ return V32QImode;
+ case E_HImode:
+ return V32HImode;
+ case E_SImode:
+ return V32SImode;
+ case E_DImode:
+ return V32DImode;
+ case E_SFmode:
+ return V32SFmode;
+ case E_DFmode:
+ return V32DFmode;
+ default:
+ return word_mode;
+ }
+
switch (mode)
{
case E_QImode:
