[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