r600g: fix the representation of control-flow instructions

We need something that looks like a compiler and not like some hacker
put some functions together. /rant

This is a band-aid for these two problems:
- The R600 and EG control-flow instructions appear in switch statements
  next to each other, causing conflicts when adding new instructions.
- The ALU control-flow instructions are bitshifted by 3 (from CF_INST 26:29
  to CF_INST 23:29, as is defined by r600 ISA) even for EG, where CF_INST
  is 22:29.

To fix this mess, the 'inst' field is bitshifted to the left either by 22, 23,
or 26 (directly in the definitions), such that it can be just or'd when making
bytecode without any shifting. All switch statements have been divided into
two, one for R600 and the other for EG.

Of course, there is a better way to do this, but that is left for future
work.

Tested on RV730 and REDWOOD with no regressions.

v2: minor cleanup as per Alex's comment.

Reviewed-by: Alex Deucher <[email protected]>

1 files changed, 6 insertions, 0 deletions

diff --git a/src/gallium/drivers/r600/r600_asm.h b/src/gallium/drivers/r600/r600_asm.h
index f4a6cfd33d6..0fd44677c34 100644
--- a/src/gallium/drivers/r600/r600_asm.h
+++ b/src/gallium/drivers/r600/r600_asm.h
@@ -109,7 +109,10 @@ struct r600_bytecode_output {
 	unsigned			array_base;
 	unsigned			type;
 	unsigned			end_of_program;
+
+	/* CF_INST. This is already bit-shifted and only needs to be or'd for bytecode. */
 	unsigned			inst;
+
 	unsigned			elem_size;
 	unsigned			gpr;
 	unsigned			swizzle_x;
@@ -128,7 +131,10 @@ struct r600_bytecode_kcache {
 
 struct r600_bytecode_cf {
 	struct list_head		list;
+
+	/* CF_INST. This is already bit-shifted and only needs to be or'd for bytecode. */
 	unsigned			inst;
+
 	unsigned			addr;
 	unsigned			ndw;
 	unsigned			id;