From: Jeff Law <law@redhat.com>
To: Richard Guenther <richard.guenther@gmail.com>
Cc: Jiangning Liu <jiangning.liu@arm.com>, gcc@gcc.gnu.org
Subject: Re: A case that PRE optimization hurts performance
Date: Tue, 27 Sep 2011 21:56:00 -0000 [thread overview]
Message-ID: <4E81E7D9.501@redhat.com> (raw)
In-Reply-To: <CAFiYyc0BSfmQtKwcCu-3+4Wgwyq92mo56k8YB9sy8OCFfxQEVQ@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/27/11 09:00, Richard Guenther wrote:
>> The thing to remember is jump threading is tasked detecting
>> cases where the control statement has a predetermined destination
>> utilizing path sensitive information. Expanding it to do
>> general path sensitive optimizations is possible, but at even
>> greater cost.
>
> Yeah, I realize that. It's just this case is the non-cfg form of
>
> if (pretmp) if (D.1234) ...
>
> where jump-threading would probably handle the CFG variant just
> fine.
Possibly. I haven't looked at the RTL version in a long long time,
but it's still around cfgcleanup::thread_jump. I've been meaning to
do some final experiments and declare that code as effectively dead
(yes, it still does stuff, but not much, at least not last time I looked).
WRT generalized path sensitive optimizations, the best work I've seen
in the space is from Bodik. I've been wanting to play with some of
his ideas for path isolation to simplify our current jump threading
implementation.
In theory, if that experiment works out we could utilize that
infrastructure to implement other path sensitive analysis and
optimization. Obviously, that's a ways out.
jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOgefZAAoJEBRtltQi2kC7JDEH+gOr0BWdN/Ru9oE7Fng1SJvX
adH9HnT0PhVhvbZQuF9Ag3HYYFOZumNgEI5HU2s3gPaFNU/KuUMcCBAD7V/1748P
L4soNu/dyHVZnKFtjx8MKEe9Jc+UMIvfdjewlsGHjzyBoXDIDaqzqQGmBLtM9MjK
gV/tKzdeYz0TB4QMKb27RIBtrZn+l6Ur6IC/PJBxB6qrimvxbet8qxgj+0RDf5XE
QSvCTS77QbfSw8k/5X1ag2lRKSZqX15w+p2b7S60XdvVd4pcIcyYKvyMDUcGy2hl
PEay76+XyFsO8bCcLg69i+UirBrfceE2CVzYYkMfsPxh2RgBViluTveeybblkLs=
=kkAA
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2011-09-27 15:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4e3762ed.030d440a.1143.2af2SMTPIN_ADDED@mx.google.com>
2011-08-02 9:23 ` Richard Guenther
2011-09-16 2:01 ` Jiangning Liu
[not found] ` <4e72add8.c9d0e30a.142a.ffffe60eSMTPIN_ADDED@mx.google.com>
2011-09-23 20:25 ` Richard Guenther
2011-09-26 8:34 ` Jiangning Liu
[not found] ` <4e802c3d.94ebd80a.4b1f.ffff8101SMTPIN_ADDED@mx.google.com>
2011-09-26 14:33 ` Richard Guenther
2011-09-27 7:30 ` Jeff Law
2011-09-27 11:15 ` Jiangning Liu
2011-09-27 13:44 ` Richard Guenther
2011-09-27 18:59 ` Jeff Law
2011-09-27 18:59 ` Richard Guenther
2011-09-27 21:56 ` Jeff Law [this message]
2011-08-02 2:37 Jiangning Liu
2011-08-15 8:40 ` Václav Zeman
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=4E81E7D9.501@redhat.com \
--to=law@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=jiangning.liu@arm.com \
--cc=richard.guenther@gmail.com \
/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).