From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id BBC1B3858D39; Mon, 15 Nov 2021 15:58:59 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BBC1B3858D39
From: "jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/103223] [12 regression] Access attribute
 dropped when ipa-sra is applied
Date: Mon, 15 Nov 2021 15:58:59 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jamborm at gcc dot gnu.org
X-Bugzilla-Status: WAITING
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-103223-4-wJZiijdN0n@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-103223-4@http.gcc.gnu.org/bugzilla/>
References: <bug-103223-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2021 15:58:59 -0000

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

--- 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:
>=20
>        /* Type attributes can use parameter indices to describe them.  */
>        if (TYPE_ATTRIBUTES (TREE_TYPE (node->decl))
>          node->can_change_signature =3D false
> Which unfortunately triggers on many C functions now when we introduced t=
he
> access attribute.
>=20
> Updating happens in ipa-param-manipulation and we do have infrastructure =
how
> to rewrite (suriving) old attributes to new ones, so we could support acc=
ess
> 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).

>=20
> I don't think possible warnings should inhibit useful optimizations and t=
his
> is a regression wrt compilers before the access attribute.  I am having
> patch to fix similar issue with fnspec attribute that can be safely remov=
ed
> at signature change since we now can preserve info in ipa-modref.
>=20
> Martin, I wonder if if you would be OK with simply dropping the access wh=
en
> 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.

>=20
> 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 entri=
es
> that was really optimized out IMO

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