[RFC] gcc: xtensa: use salt/saltu in xtensa_expand_scc

[RFC] gcc: xtensa: use salt/saltu in xtensa_expand_scc

[Max Filippov]

gcc/
	* config/xtensa/predicates.md (xtensa_cstoresi_operator): Add
	unsigned comparisons.
	* config/xtensa/xtensa.cc (xtensa_expand_scc): Add code
	generation of salt/saltu instructions.
	* config/xtensa/xtensa.h (TARGET_SALT): New macro.
	* gcc/config/xtensa/xtensa.md (salt, saltu): New instruction
	patterns.
---
I've tested it both with configurations that have salt/saltu and that
don't.
The inversion of the result at the end looks wasteful. I've been reading
gccint chapter about cstoreMODE4 and the following part left me with the
question:

  The value stored for a true condition must have 1 as its low bit,
  or else must be negative.

Does it mean that some variants of cstoreMODE4 may return 1 and some may
return -1 for truth, as both have 1 as its low bit? If that's true we
could use 'addi dest, dest, -1' instead of two-intruction sequence
'movi tmp, 1; xor dest, dest, tmp'.

---
 gcc/config/xtensa/predicates.md |  2 +-
 gcc/config/xtensa/xtensa.cc     | 58 +++++++++++++++++++++++++++++++++
 gcc/config/xtensa/xtensa.h      |  1 +
 gcc/config/xtensa/xtensa.md     | 20 ++++++++++++
 4 files changed, 80 insertions(+), 1 deletion(-)

diff --git a/gcc/config/xtensa/predicates.md b/gcc/config/xtensa/predicates.md
index a3575a688923..672fb003a6c5 100644
--- a/gcc/config/xtensa/predicates.md
+++ b/gcc/config/xtensa/predicates.md
@@ -195,7 +195,7 @@
   (match_code "plus,minus"))
 
 (define_predicate "xtensa_cstoresi_operator"
-  (match_code "eq,ne,gt,ge,lt,le"))
+  (match_code "eq,ne,gt,ge,lt,le,gtu,geu,ltu,leu"))
 
 (define_predicate "xtensa_shift_per_byte_operator"
   (match_code "ashift,ashiftrt,lshiftrt"))
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 1afaa1cc94e7..cc63529e80ea 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -1028,6 +1028,64 @@ xtensa_expand_scc (rtx operands[4], machine_mode cmp_mode)
 	break;
       }
 
+  if (cmp_mode == SImode && TARGET_SALT)
+    {
+      bool swap_args = false;
+      bool invert_res = false;
+      rtx a = operands[2], b = force_reg (SImode, operands[3]);
+
+      switch (code)
+	{
+	case GE:
+	case GEU:
+	  invert_res = true;
+	  break;
+	case GT:
+	case GTU:
+	  swap_args = true;
+	  break;
+	case LE:
+	case LEU:
+	  invert_res = true;
+	  swap_args = true;
+	  break;
+	default:
+	  break;
+	}
+
+      if (swap_args)
+	std::swap (a, b);
+
+      switch (code)
+	{
+	case GE:
+	case GT:
+	case LE:
+	case LT:
+	  emit_insn (gen_salt (dest, a, b));
+	  if (!invert_res)
+	    return 1;
+	  break;
+	case GEU:
+	case GTU:
+	case LEU:
+	case LTU:
+	  emit_insn (gen_saltu (dest, a, b));
+	  if (!invert_res)
+	    return 1;
+	  break;
+	default:
+	  break;
+	}
+
+      if (invert_res)
+	{
+	  one_tmp = force_reg (SImode, const1_rtx);
+	  emit_insn (gen_xorsi3 (dest, dest, one_tmp));
+	  return 1;
+	}
+    }
+
   if (! (cmp = gen_conditional_move (code, cmp_mode,
 				     operands[2], operands[3])))
     return 0;
diff --git a/gcc/config/xtensa/xtensa.h b/gcc/config/xtensa/xtensa.h
index 34e06afcff48..5987681e5496 100644
--- a/gcc/config/xtensa/xtensa.h
+++ b/gcc/config/xtensa/xtensa.h
@@ -54,6 +54,7 @@ along with GCC; see the file COPYING3.  If not see
 #define TARGET_WINDOWED_ABI	xtensa_windowed_abi
 #define TARGET_DEBUG		XCHAL_HAVE_DEBUG
 #define TARGET_L32R		XCHAL_HAVE_L32R
+#define TARGET_SALT		(XTENSA_MARCH_EARLIEST >= 260000)
 
 #define TARGET_DEFAULT (MASK_SERIALIZE_VOLATILE)
 
diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index d6505e7eb700..594238030237 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -2393,6 +2393,26 @@
   DONE;
 })
 
+(define_insn "salt"
+  [(set (match_operand:SI 0 "register_operand" "=a")
+	(lt:SI (match_operand:SI 1 "register_operand" "r")
+	       (match_operand:SI 2 "register_operand" "r")))]
+  "TARGET_SALT"
+  "salt\t%0, %1, %2"
+  [(set_attr "type"	"arith")
+   (set_attr "mode"	"SI")
+   (set_attr "length"	"3")])
+
+(define_insn "saltu"
+  [(set (match_operand:SI 0 "register_operand" "=a")
+	(ltu:SI (match_operand:SI 1 "register_operand" "r")
+		(match_operand:SI 2 "register_operand" "r")))]
+  "TARGET_SALT"
+  "saltu\t%0, %1, %2"
+  [(set_attr "type"	"arith")
+   (set_attr "mode"	"SI")
+   (set_attr "length"	"3")])
+
 (define_expand "cstoresf4"
   [(match_operand:SI 0 "register_operand")
    (match_operator:SI 1 "comparison_operator"
-- 
2.30.2

Re: [RFC] gcc: xtensa: use salt/saltu in xtensa_expand_scc

[Takayuki 'January June' Suwa]

Hi!

On 2023/09/07 23:22, Max Filippov wrote:
> gcc/
> 	* config/xtensa/predicates.md (xtensa_cstoresi_operator): Add
> 	unsigned comparisons.
> 	* config/xtensa/xtensa.cc (xtensa_expand_scc): Add code
> 	generation of salt/saltu instructions.
> 	* config/xtensa/xtensa.h (TARGET_SALT): New macro.
> 	* gcc/config/xtensa/xtensa.md (salt, saltu): New instruction
> 	patterns.
> ---
> I've tested it both with configurations that have salt/saltu and that
> don't.
> The inversion of the result at the end looks wasteful. I've been reading
> gccint chapter about cstoreMODE4 and the following part left me with the
> question:
> 
>   The value stored for a true condition must have 1 as its low bit,
>   or else must be negative.
> 
> Does it mean that some variants of cstoreMODE4 may return 1 and some may
> return -1 for truth, as both have 1 as its low bit?

IMHO it is nothing more than the fact that there are two possible integer constants that represent 'true' (the result of !0), namely either 1 or -1.
And given a certain target and configuration, it must be consistently fixed to one value or the other; for Xtensa, it should be an integer constant of 1.

>                                                      If that's true we
> could use 'addi dest, dest, -1' instead of two-intruction sequence
> 'movi tmp, 1; xor dest, dest, tmp'.

An alternative way to convert 1 to 0 and 0 to 1:

	neg	dest, dest
	addi	dest, 1

This requires no temporary register.