From: Martin Jambor <mjambor@suse.cz>
To: GCC Patches <gcc-patches@gcc.gnu.org>
Cc: Richard Guenther <rguenther@suse.de>, Jan Hubicka <hubicka@ucw.cz>
Subject: [PATCH, PR 45934 0/6] Devirtualization aware of dynamic type changes
Date: Wed, 01 Dec 2010 20:22:00 -0000 [thread overview]
Message-ID: <20101201201618.861802217@virgil.suse.cz> (raw)
Hi,
this series of patches is another attempt to address dynamic type
changes, a followup to
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02296.html.
Sorry it took me so long. It took me a few days to figure out exactly
what to do and how to justify it and then I started splitting the
patch into separate steps and making them at lest somewhat pretty and
that took even more time. Last but not least, this patch set also
fixes PR 46302 which the previous one did not because somehow one
important call to detect_type_change got lost in the process. I have
added an extra testcase for that situation.
The series is divided into the following patches. The division wasn't
smooth all the time, on two or three occasions a subsequent patch
undoes some tiny change introduced in a previous one.
1. A re-post of
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02291.html, already
reviewed by Richi but still waiting for Honza's approval. Yep,
this is basically a ping.
2. Disabling devirtualization in folding and that based on global
variables which do not work because of dynamic type changes.
3. More robust compute_complex_ancestor_jump_func - a slight
improvement in jump function building.
4. Detecting dynamic type changes of objects with virtual methods and
disabling devirtualization upon their encounter.
5. Identifying the new dynamic type of an object after such change
when we can do so and using it to drive devirtualization instead of
disabling it.
6. Intraprocedural BINFO-based devirtualization. Necessary to perform
devirtualization when there is no IPA transfer of information
involved.
More details about individual steps are in the corresponding email
messages.
I'm about to start working on a separate switch for controlling
devirtualization - I intend to put it in between the last two patches
in the above series.
Thanks for all feedback, including that I have already received as
comments to the previous version of this patch,
Martin
next reply other threads:[~2010-12-01 20:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-01 20:22 Martin Jambor [this message]
2010-12-01 20:22 ` [PATCH, PR 45934 3/6] More robust compute_complex_ancestor_jump_func Martin Jambor
2010-12-01 20:28 ` Richard Guenther
2010-12-01 20:23 ` [PATCH, PR 45934 2/6] Remove devirtualizations that cannot be done Martin Jambor
2010-12-01 20:35 ` Richard Guenther
2010-12-02 10:46 ` Martin Jambor
2010-12-02 12:14 ` Richard Guenther
2010-12-01 20:23 ` [PATCH, PR 45934 5/6] Identify the new dynamic type after change Martin Jambor
2010-12-01 20:23 ` [PATCH, PR 45934 1/6] [PR 46287] Do not generate direct calls to thunks Martin Jambor
2010-12-01 20:58 ` Jan Hubicka
2010-12-03 13:01 ` Martin Jambor
2010-12-14 17:39 ` Jan Hubicka
2010-12-15 15:15 ` Martin Jambor
2010-12-15 15:46 ` Jan Hubicka
2010-12-15 16:52 ` Martin Jambor
2010-12-17 14:14 ` H.J. Lu
2010-12-01 20:23 ` [PATCH, PR 45934 6/6] Intraprocedural type-based devirtualization Martin Jambor
2010-12-02 15:40 ` Richard Guenther
2010-12-01 20:23 ` [PATCH, PR 45934 4/6] Dynamic type change detection Martin Jambor
2010-12-02 15:19 ` Richard Guenther
2010-12-02 16:17 ` Richard Guenther
2010-12-09 11:30 ` Martin Jambor
2010-12-02 23:25 ` Jason Merrill
2010-12-03 13:45 ` Martin Jambor
2010-12-03 14:34 ` Gabriel Dos Reis
2010-12-03 16:07 ` Jason Merrill
2010-12-03 16:09 ` Richard Guenther
2010-12-03 16:21 ` Gabriel Dos Reis
2010-12-04 23:14 ` Jason Merrill
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=20101201201618.861802217@virgil.suse.cz \
--to=mjambor@suse.cz \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=rguenther@suse.de \
/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).