public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/55683] [4.8 Regression] ICE in inline_call, at ipa-inline-transform.c:270
Date: Thu, 10 Jan 2013 16:59:00 -0000 [thread overview]
Message-ID: <bug-55683-4-4CxXchOIcl@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-55683-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55683
--- Comment #15 from Martin Jambor <jamborm at gcc dot gnu.org> 2013-01-10 16:58:35 UTC ---
(In reply to comment #13)
> The acutal ICE should be fixed. Martinj, I will leave the PR open
> just to make you to double check that ipa-cp is doing properly the
> translation from constants to binfos, too.
At -O2, IPA-CP does not even consider cloning C::c1 because it is not
allowed to grow code by creating clones.
At -O3 (or with -fipa-cp-clone), IPA-CP discovers that cloning for &c
would lead to devirtualization but because the target of the
devirtualized call is not analyzed, it gets only minimal bonus for
that. Eventually the cloning opportunity gets score 437 (cloning
threshold is 500) and thus it is dropped. This is as it should be.
> I would expect this testcase to be caught by ipa-cp prior inlining. Also I
> think that when merging values, we should go from constant to binfo when
> constants differs but their binfos match (so when method is called with
> multiple static instances of the same object we will get devirtualization). I
> don't see ipa-cp doing that.
Well, the problem with that of course is that we do not merge stuff
now, we accumulate all possible constants. So what we perhaps should
do instead is (if ipcp_param_lattices->virt_call is true) to try to
see if a number of ADDR_EXPR constants yield the same binfo and if so,
consider that new value first, before any real constants.
prev parent reply other threads:[~2013-01-10 16:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-14 8:56 [Bug tree-optimization/55683] New: " rguenth at gcc dot gnu.org
2012-12-14 8:57 ` [Bug tree-optimization/55683] " rguenth at gcc dot gnu.org
2012-12-14 8:59 ` rguenth at gcc dot gnu.org
2012-12-14 9:57 ` jakub at gcc dot gnu.org
2012-12-14 10:26 ` rguenth at gcc dot gnu.org
2012-12-14 10:31 ` jakub at gcc dot gnu.org
2012-12-14 10:43 ` rguenth at gcc dot gnu.org
2012-12-14 12:14 ` jamborm at gcc dot gnu.org
2012-12-16 11:58 ` rguenth at gcc dot gnu.org
2012-12-18 12:47 ` rguenth at gcc dot gnu.org
2012-12-18 13:40 ` hubicka at ucw dot cz
2012-12-18 16:40 ` hubicka at gcc dot gnu.org
2012-12-18 17:16 ` hubicka at gcc dot gnu.org
2012-12-19 11:42 ` hubicka at gcc dot gnu.org
2012-12-19 11:47 ` hubicka at gcc dot gnu.org
2012-12-19 15:28 ` rguenth at gcc dot gnu.org
2013-01-10 16:59 ` jamborm at gcc dot gnu.org [this message]
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-55683-4-4CxXchOIcl@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).