[gcc r14-6426] strub: add note on attribute access

Alexandre Oliva aoliva@gcc.gnu.org
Mon Dec 11 18:32:18 GMT 2023


https://gcc.gnu.org/g:e4fc59e0d50cd3d2bb3a004fff135f5955621d01

commit r14-6426-ge4fc59e0d50cd3d2bb3a004fff135f5955621d01
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Mon Dec 11 15:09:13 2023 -0300

    strub: add note on attribute access
    
    Document why attribute access doesn't need the same treatment as fn
    spec, and check that the assumption behind it holds.
    
    
    for  gcc/ChangeLog
    
            * ipa-strub.cc (pass_ipa_strub::execute): Check that we don't
            add indirection to pointer parameters, and document attribute
            access non-interactions.

Diff:
---
 gcc/ipa-strub.cc | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/gcc/ipa-strub.cc b/gcc/ipa-strub.cc
index 2afb7a45575..8ec6824e8a8 100644
--- a/gcc/ipa-strub.cc
+++ b/gcc/ipa-strub.cc
@@ -2889,6 +2889,13 @@ pass_ipa_strub::execute (function *)
 		&& (tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (nparm)))
 		    <= 4 * UNITS_PER_WORD))))
 	{
+	  /* No point in indirecting pointer types.  Presumably they
+	     won't ever pass the size-based test above, but check the
+	     assumption here, because getting this wrong would mess
+	     with attribute access and possibly others.  We deal with
+	     fn spec below.  */
+	  gcc_checking_assert (!POINTER_TYPE_P (TREE_TYPE (nparm)));
+
 	  indirect_nparms.add (nparm);
 
 	  /* ??? Is there any case in which it is not safe to suggest the parms
@@ -2976,7 +2983,9 @@ pass_ipa_strub::execute (function *)
 		}
 	    }
 
-	/* ??? Maybe we could adjust it instead.  */
+	/* ??? Maybe we could adjust it instead.  Note we don't need
+	   to mess with attribute access: pointer-typed parameters are
+	   not modified, so they can remain unchanged.  */
 	if (drop_fnspec)
 	  remove_named_attribute_unsharing ("fn spec",
 					    &TYPE_ATTRIBUTES (nftype));


More information about the Gcc-cvs mailing list