public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Matthew Malcomson <matmal01@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc(refs/vendors/ARM/heads/morello)] Add folding for replace_address_value
Date: Fri, 21 Oct 2022 13:21:34 +0000 (GMT)	[thread overview]
Message-ID: <20221021132134.5AADB385383F@sourceware.org> (raw)

https://gcc.gnu.org/g:5ecdb56f3dcea8d16b9d60bae90a0af35990f194

commit 5ecdb56f3dcea8d16b9d60bae90a0af35990f194
Author: Matthew Malcomson <matthew.malcomson@arm.com>
Date:   Fri Oct 21 14:18:49 2022 +0100

    Add folding for replace_address_value
    
    This failure to fold a REPLACE_ADDRESS_VALUE internal function call was
    causing some test failures in the libstdc++ testsuite when using an
    integer casted to a pointer as a parameter in a builtin function call
    that the testcase required to get folded away.
    
    The initial call to `fold_build_replace_address_value_loc` is made with
    a relatively complex tree as its argument (the "capability value" is
    given as the negate_expr of a constant) which is something that we
    really don't want to have to handle.
    
    However it seems that in the C++ frontend more folding is attempted
    later on.  This folding is attempted using the general function `fold`
    defined in fold-const.c.  This is called via `cp_fold`.  If we simply
    allow this function to handle the same sort of a REPLACE_ADDRESS_VALUE
    on INTEGER_CST arguments that we already handle while building the
    internal function call then we observe that the required folding
    happens.
    
    N.b. based on some comments in `c_fully_fold_internal`, I believe that
    handling replace_address_value in `fold` was not necessary for the C
    language since the C language already handled all folding of function
    arguments while building the expression up.  Hence this does not appear
    to have changed the C frontend behaviour.

Diff:
---
 gcc/fold-const.c | 57 +++++++++++++++++++++++++++++++++++++++-----------------
 gcc/fold-const.h |  1 +
 2 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 39cd66af522..e551cc7c216 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -13026,7 +13026,11 @@ fold (tree expr)
     {
       if (code == CALL_EXPR)
 	{
-	  tem = fold_call_expr (loc, expr, false);
+	  if (CALL_EXPR_FN (expr) == NULL_TREE
+	      && CALL_EXPR_IFN (expr) == IFN_REPLACE_ADDRESS_VALUE)
+	    tem = fold_replace_address_value_loc (loc, expr);
+	  else
+	    tem = fold_call_expr (loc, expr, false);
 	  return tem ? tem : expr;
 	}
       return expr;
@@ -13638,27 +13642,21 @@ fold_build_call_array_initializer_loc (location_t loc, tree type, tree fn,
 #undef START_FOLD_INIT
 #undef END_FOLD_INIT
 
-/* Build REPLACE_ADDRESS_VALUE internal function, folding away constant
-   assignments if possible.
-
-   We currently only fold away assignments to a constant 0 capability to make
-   constant integer initialisation work nicely, but this could be made to work
-   on assignments to any integer_cst capability.  */
+/* Helper for both fold_build_replace_address_value_loc and
+   fold_build_replace_address_value.  This implements the folding for both.
 
-tree
-fold_build_replace_address_value_loc (location_t loc, tree c, tree cv)
+   We only handle expressions which we know are constants.  */
+static tree
+fold_replace_address_value_1 (location_t loc, tree c, tree cv)
 {
-  if (! tree_is_capability_value (c))
-    return fold_convert (TREE_TYPE (c), cv);
-  gcc_assert (INTEGRAL_TYPE_P (TREE_TYPE (cv))
-	      && TYPE_PRECISION (TREE_TYPE (cv))
-		<= TYPE_PRECISION (noncapability_type (TREE_TYPE (c))));
-
-  tree orig_c = c;
   tree orig_cv = cv;
   STRIP_ANY_LOCATION_WRAPPER (c);
   STRIP_ANY_LOCATION_WRAPPER (cv);
 
+  gcc_assert (INTEGRAL_TYPE_P (TREE_TYPE (cv))
+	      && TYPE_PRECISION (TREE_TYPE (cv))
+		<= TYPE_PRECISION (noncapability_type (TREE_TYPE (c))));
+
   if (TREE_CODE (c) == INTEGER_CST && TREE_CODE (cv) == INTEGER_CST)
     {
       tree cap_type = TREE_TYPE (c);
@@ -13690,7 +13688,32 @@ fold_build_replace_address_value_loc (location_t loc, tree c, tree cv)
 						   CALL_EXPR_ARG (c, 0), orig_cv);
     }
 
-  return build_replace_address_value_loc (loc, orig_c, orig_cv);
+  return NULL_TREE;
+}
+
+/* Build REPLACE_ADDRESS_VALUE internal function, folding away constant
+   assignments if possible.  */
+tree
+fold_build_replace_address_value_loc (location_t loc, tree c, tree cv)
+{
+  if (! tree_is_capability_value (c))
+    return fold_convert (TREE_TYPE (c), cv);
+
+  tree tmp = fold_replace_address_value_1 (loc, c, cv);
+  if (tmp)
+    return tmp;
+
+  return build_replace_address_value_loc (loc, c, cv);
+}
+
+/* Fold a REPLACE_ADDRESS_VALUE internal function call, folding away constant
+   assignments and constant recursive calls.  */
+tree
+fold_replace_address_value_loc (location_t loc, tree exp)
+{
+  tree c = CALL_EXPR_ARG (exp, 0);
+  tree cv = CALL_EXPR_ARG (exp, 1);
+  return fold_replace_address_value_1 (loc, c, cv);
 }
 
 tree
diff --git a/gcc/fold-const.h b/gcc/fold-const.h
index 738e2d0fc51..904e01dd9f0 100644
--- a/gcc/fold-const.h
+++ b/gcc/fold-const.h
@@ -79,6 +79,7 @@ extern tree get_array_ctor_element_at_index (tree, offset_int,
 #define fold_build_replace_address_value(T1, T2)\
    fold_build_replace_address_value_loc (UNKNOWN_LOCATION, T1, T2)
 extern tree fold_build_replace_address_value_loc (location_t, tree, tree);
+extern tree fold_replace_address_value_loc (location_t, tree);
 extern tree maybe_cap_int_const_binop (tree_code, tree, tree);
 extern bool fold_convertible_p (const_tree, const_tree);
 #define fold_convert(T1,T2)\

                 reply	other threads:[~2022-10-21 13:21 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20221021132134.5AADB385383F@sourceware.org \
    --to=matmal01@gcc.gnu.org \
    --cc=gcc-cvs@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).