public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Roger Sayle" <roger@nextmovesoftware.com>
To: "'GCC Patches'" <gcc-patches@gcc.gnu.org>
Subject: [RFC] Experimental __attribute__((saturating)) on integer types.
Date: Sun, 26 Sep 2021 21:37:52 +0100	[thread overview]
Message-ID: <008b01d7b316$63e54060$2bafc120$@nextmovesoftware.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2881 bytes --]


This patch is prototype proof-of-concept (and request for feedback)
that touches the front-end, middle-end and backend.  My recent patch to
perform RTL constant folding of saturating arithmetic revealed how
difficult it is to generate a (portable) test case for that functionality.
This patch experiments with adding an "saturating" attribute to the
C-family front-ends to set the TYPE_SATURATING flag on integer types,
initially as a debugging/testing tool for the middle-end.  GCC already
contains logic during RTL expansion to emit [us]s_plus and [us]s_minus
instructions via the standard named [us]ss{add,sub}<mode>3 optabs.

Disappointingly, although the documentation for ssplus<mode>3 patterns
implies this should work for arbitrary (i.e. integer) modes, the
optab querying infrastructure (based on optabs.def) is currently
limited to fixed-point modes.  Hence the patch below contains a
tweak to optabs.def.

With both of the above pieces in place, GCC can now generate an
ssaddsi3 instruction (such as the example provided for the nvptx
backend), or ICE if the required saturating operation doesn't exist,
as libgcc doesn't (yet) provide fall-back implementations for
saturating signed and unsigned arithmetic.

Sticking with the positive, the following code:

typedef int sat_int32 __attribute__ ((saturating));
int ssadd32(int x, int y) {
  sat_int32 t = (sat_int32)x + (sat_int32)y;
  return (int)t;
}

with this patch, now generates the following on nvptx-none:

mov.u32 %r23, %ar0;
mov.u32 %r24, %ar1;
add.sat.s32     %value, %r23, %r24;


Are any of the independent chunks below suitable for the compiler?
Tested on nvptx-none and x86_64-pc-linux-gnu, but nothing changes
unless __attribute__ ((saturating)) is explicitly added to the source
code [and I'd recommend against that except for testing purposes].

Eventually saturating arithmetic such as this might be useful for
kernel security (a hot topic of last week's Linux Plumbers' Conference)
but it would require a lot of polishing to clean-up the rough edges
(and ideally better hardware support).

Thoughts?  Even if a new C-family attribute is unsuitable, is my
logic/implementation in handle_saturating_attribute correct?


2021-09-26  Roger Sayle  <roger@nextmovesoftware.com>

gcc/c-family/ChangeLog
	* c-attribs (handle_saturating_attribute): New callback function
	for a "saturating" attribute to set the TYPE_SATURATING flag on
	an integer type.
	(c_common_attribute_table): New entry for "saturating".

gcc/ChangeLog
	* config/nvptx/nvptx.md (ssaddsi3, sssubsi3): New define_insn
	patterns for SImode saturating addition/subtraction respectively.

	* optabs.def (ssadd_optab, usadd_optab, ssub_optab, usub_optab):
	Allow querying of integer modes in addition to fixed-point modes.

	* print-tree.c (print_node): Output "saturating" when the
	TYPE_SATURATING flag is set on integer types.

Roger
--


[-- Attachment #2: patchy.txt --]
[-- Type: text/plain, Size: 4448 bytes --]

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 007b928..cd58605 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -169,6 +169,7 @@ static tree handle_objc_nullability_attribute (tree *, tree, tree, int, bool *);
 static tree handle_signed_bool_precision_attribute (tree *, tree, tree, int,
 						    bool *);
 static tree handle_retain_attribute (tree *, tree, tree, int, bool *);
+static tree handle_saturating_attribute (tree *, tree, tree, int, bool *);
 
 /* Helper to define attribute exclusions.  */
 #define ATTR_EXCL(name, function, type, variable)	\
@@ -536,6 +537,8 @@ const struct attribute_spec c_common_attribute_table[] =
 			      handle_special_var_sec_attribute, attr_section_exclusions },
   { "access",		      1, 3, false, true, true, false,
 			      handle_access_attribute, NULL },
+  { "saturating",	      0, 0, false, true, false, false,
+			      handle_saturating_attribute, NULL },
   /* Attributes used by Objective-C.  */
   { "NSObject",		      0, 0, true, false, false, false,
 			      handle_nsobject_attribute, NULL },
@@ -5761,6 +5764,27 @@ handle_objc_nullability_attribute (tree *node, tree name, tree args,
   return NULL_TREE;
 }
 
+/* Handle a "saturating" attribute.  */
+
+static tree
+handle_saturating_attribute (tree *node, tree name, tree ARG_UNUSED (args),
+			     int flags, bool *no_add_attrs)
+{
+  tree type = *node;
+
+  *no_add_attrs = true;
+
+  if (TREE_CODE (type) == INTEGER_TYPE)
+    {
+      if (!(flags & (int) ATTR_FLAG_TYPE_IN_PLACE))
+	*node = type = build_duplicate_type (type);
+      TYPE_SATURATING (type) = 1;
+    }
+  else
+    warning (OPT_Wattributes,"saturating attribute on non-integer type");
+  return NULL_TREE;
+}
+
 /* Attempt to partially validate a single attribute ATTR as if
    it were to be applied to an entity OPER.  */
 
diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index 108de1c..79fa300 100644
--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -1217,6 +1217,22 @@
   return asms[INTVAL (operands[2])];
 })
 
+;; Saturating integer arithmetic
+
+(define_insn "ssaddsi3"
+  [(set (match_operand:SI 0 "nvptx_register_operand" "=R")
+	(ss_plus:SI (match_operand:SI 1 "nvptx_register_operand" "R")
+		    (match_operand:SI 2 "nvptx_nonmemory_operand" "Ri")))]
+  ""
+  "%.\\tadd.sat.s32\\t%0, %1, %2;")
+
+(define_insn "sssubsi3"
+  [(set (match_operand:SI 0 "nvptx_register_operand" "=R")
+	(ss_minus:SI (match_operand:SI 1 "nvptx_register_operand" "R")
+		     (match_operand:SI 2 "nvptx_register_operand" "R")))]
+  ""
+  "%.\\tsub.sat.s32\\t%0, %1, %2;")
+
 ;; Miscellaneous
 
 (define_insn "nop"
diff --git a/gcc/optabs.def b/gcc/optabs.def
index 201b8aa..7d157ad 100644
--- a/gcc/optabs.def
+++ b/gcc/optabs.def
@@ -106,14 +106,18 @@ OPTAB_NX(add_optab, "add$Q$a3")
 OPTAB_VL(addv_optab, "addv$I$a3", PLUS, "add", '3', gen_intv_fp_libfunc)
 OPTAB_VX(addv_optab, "add$F$a3")
 OPTAB_NL(ssadd_optab, "ssadd$Q$a3", SS_PLUS, "ssadd", '3', gen_signed_fixed_libfunc)
+OPTAB_NX(ssadd_optab, "ssadd$I$a3")
 OPTAB_NL(usadd_optab, "usadd$Q$a3", US_PLUS, "usadd", '3', gen_unsigned_fixed_libfunc)
+OPTAB_NX(usadd_optab, "usadd$I$a3")
 OPTAB_NL(sub_optab, "sub$P$a3", MINUS, "sub", '3', gen_int_fp_fixed_libfunc)
 OPTAB_NX(sub_optab, "sub$F$a3")
 OPTAB_NX(sub_optab, "sub$Q$a3")
 OPTAB_VL(subv_optab, "subv$I$a3", MINUS, "sub", '3', gen_intv_fp_libfunc)
 OPTAB_VX(subv_optab, "sub$F$a3")
 OPTAB_NL(sssub_optab, "sssub$Q$a3", SS_MINUS, "sssub", '3', gen_signed_fixed_libfunc)
+OPTAB_NX(sssub_optab, "sssub$I$a3")
 OPTAB_NL(ussub_optab, "ussub$Q$a3", US_MINUS, "ussub", '3', gen_unsigned_fixed_libfunc)
+OPTAB_NX(sssub_optab, "ussub$I$a3")
 OPTAB_NL(smul_optab, "mul$Q$a3", MULT, "mul", '3', gen_int_fp_fixed_libfunc)
 OPTAB_NX(smul_optab, "mul$P$a3")
 OPTAB_NX(smul_optab, "mul$F$a3")
diff --git a/gcc/print-tree.c b/gcc/print-tree.c
index d1fbd04..d0e135e 100644
--- a/gcc/print-tree.c
+++ b/gcc/print-tree.c
@@ -620,6 +620,10 @@ print_node (FILE *file, const char *prefix, tree node, int indent,
 	  && TYPE_REVERSE_STORAGE_ORDER (node))
 	fputs (" reverse-storage-order", file);
 
+      if (code == INTEGER_TYPE
+	  && TYPE_SATURATING (node))
+	fputs(" saturating", file);
+
       if ((code == RECORD_TYPE
 	   || code == UNION_TYPE)
 	  && TYPE_CXX_ODR_P (node))

             reply	other threads:[~2021-09-26 20:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-26 20:37 Roger Sayle [this message]
2021-09-27 13:45 ` Richard Biener
2021-09-27 20:33   ` Joseph Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='008b01d7b316$63e54060$2bafc120$@nextmovesoftware.com' \
    --to=roger@nextmovesoftware.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).