public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "hubicka at kam dot mff.cuni.cz" <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 21:02:19 +0000	[thread overview]
Message-ID: <bug-103223-4-Yofu8NOuFD@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-103223-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #8 from hubicka at kam dot mff.cuni.cz ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103223
> 
> --- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
> (In reply to Martin Jambor from comment #4)
> > (In reply to Jan Hubicka from comment #0)
> ...
> > > 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.
> 
> I replied earlier on gcc-patches: I've always intended the access attribute to
> eventually benefit optimization so please feel free (and encouraged :) to use
> it
> for that purpose.  The idea behind it was not just to catch bugs but also to
> enable optimizations based on the expectation that those bugs will have been
> fixed.  (This has to be done carefully since the attribute is also implicitly
> added in contexts where relying on it wouldn't correct for optimization; the
> attirbute API makes it possible to distinguish these cases.)

Is there some summary of what information the access attribute holds
in addition to what we have in fnspec (which is used for the
optimization)?
> 
> By dropping the attribute in IPA passes we would not only give up on detecting
> the bugs the IPA transformations expose but also on the optimization
> opportunities they might open up.

Yep, I hope it is not too hard to write code updating the attribute
after transformation.  We drop the attribute only when we actually do
some change on function parameters.

ipa-modref solves similar problem of updating the modref summaries after
changes.  What I do is to simply compute map translating old parameter
indexes to new via:

  clone_info *info = clone_info::get (node);

  FOR_EACH_VEC_SAFE_ELT (info->param_adjustments->m_adj_params, i, p)
    {
      int idx = info->param_adjustments->get_original_index (i);
      if (idx > (int)max)
        max = idx;
    }

  auto_vec <int, 32> map;

  map.reserve (max + 1);
  for (i = 0; i <= max; i++)
    map.quick_push (-1);
  FOR_EACH_VEC_SAFE_ELT (info->param_adjustments->m_adj_params, i, p)
    {
      int idx = info->param_adjustments->get_original_index (i);
      if (idx >= 0)
        map[idx] = i;
    }

and then I simply rewrite old parameter indexes to new and drop parts of
info that uses parameters that was either removed or replaced by
scalars/components.

Similarly we can do for access attribute.

  parent reply	other threads:[~2021-11-15 21:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-13 10:05 [Bug tree-optimization/103223] New: [12 regression] Access attribute prevents IPA optimization hubicka at gcc dot gnu.org
2021-11-13 23:56 ` [Bug tree-optimization/103223] [12 regression] Access attribute dropped when ipa-sra is applied hubicka at gcc dot gnu.org
2021-11-15  9:02 ` rguenth at gcc dot gnu.org
2021-11-15 15:50 ` jamborm at gcc dot gnu.org
2021-11-15 15:58 ` jamborm at gcc dot gnu.org
2021-11-15 16:12 ` msebor at gcc dot gnu.org
2021-11-15 18:12 ` jamborm at gcc dot gnu.org
2021-11-15 20:19 ` msebor at gcc dot gnu.org
2021-11-15 21:02 ` hubicka at kam dot mff.cuni.cz [this message]
2021-11-15 22:32 ` msebor at gcc dot gnu.org
2021-11-22  7:35 ` admin at levyhsu dot com
2021-11-22  7:53 ` hubicka at kam dot mff.cuni.cz
2022-05-06  8:31 ` [Bug ipa/103223] [12/13 " jakub at gcc dot gnu.org
2023-05-08 12:23 ` [Bug ipa/103223] [12/13/14 " rguenth at gcc dot gnu.org

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=bug-103223-4-Yofu8NOuFD@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).