[Bug tree-optimization/103223] [12 regression] Access attribute dropped when ipa-sra is applied

["jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103223

--- Comment #4 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #0)
> Hi,
> ipa-fnsummary sets can_change_signature flag which determines whether we can
> manipulate parameters of a given function.  It tests:
> 
>        /* Type attributes can use parameter indices to describe them.  */
>        if (TYPE_ATTRIBUTES (TREE_TYPE (node->decl))
>          node->can_change_signature = false
> Which unfortunately triggers on many C functions now when we introduced the
> access attribute.
> 
> Updating happens in ipa-param-manipulation and we do have infrastructure how
> to rewrite (suriving) old attributes to new ones, so we could support access
> attribute updating (or always map to old indexes when using it).

We do?  I thought I would need to write it (together with recognizing
parameters which we can safely update/ignore).

> 
> I don't think possible warnings should inhibit useful optimizations and this
> is a regression wrt compilers before the access attribute.  I am having
> patch to fix similar issue with fnspec attribute that can be safely removed
> at signature change since we now can preserve info in ipa-modref.
> 
> Martin, I wonder if if you would be OK with simply dropping the access when
> function signature changes (which I can prepare patch for) or do you want to
> dive into updating it?

I would be OK with it but I don't think people who invested the energy
into these new security warnings would.

> 
> Once new fuction is created, for every new parameter there is
> get_original_index accessor which returns original parameter index (if it
> exists).  This could be easily used to update access and drop those entries
> that was really optimized out IMO

Yeah.  I guess that is the necessary thing to do.