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 --git a/gcc/config/gcn/gcn.cc b/gcc/config/gcn/gcn.cc
index 498146dcde9457e90863adb8fb83a40d33ce16bf..efb73af50c44eb379aa39aea1d7280c1fa575fc9 100644 (file)
--- 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: