From: Jeff Law <law@redhat.com>
To: Easwaran Raman <eraman@google.com>
Cc: gcc-patches@gcc.gnu.org, Richard Guenther <richard.guenther@gmail.com>
Subject: Re: Improve DSE in the presence of calls
Date: Mon, 25 Apr 2011 17:21:00 -0000 [thread overview]
Message-ID: <4DB5A955.7030400@redhat.com> (raw)
In-Reply-To: <BANLkTinF9U1TKke5LAeB4ywA+Cbng==5KA@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/22/11 14:19, Easwaran Raman wrote:
> Hi,
> This patch improves RTL DSE by not assuming that calls read all
> memory locations. With this patch, calls are assumed to read any
> non-frame memory and any stack variables that can potentially escape.
> This patch partly addresses PR rtl-optimization/44194. Bootstraps and
> no test regressions. OK for trunk?
>
> Thanks,
> Easwaran
>
> 2011-04-22 Easwaran Raman <eraman@google.com>
>
> PR rtl-optimization/44194
> * dse.c (header files): Include tree-flow.h.
> (group_info): Add fields.
> (globals): Add a new variable kill_on_calls.
> (get_group_info): Initialize added fields.
> (dse_step0): Initialize kill_on_calls.
> (can_escape): New function.
> (record_store): Pass EXPR corresponding to MEM to
> set_usage_bits.
> (dse_step2_nospill): Set kill_on_calls based on
> group->escaped_*.
> (scan_reads_nospill): Handle call instructions.
> (find_insn_before_first_wild_read): Remove the function.
> (dse_step3_scan): Remove call to find_insn_before_first_wild_read.
> (dse_step5_nospill): Do not kill everything on call.
>
> testsuite/ChangeLog:
>
> 2011-04-22 Easwaran Raman <eraman@google.com>
>
> PR rtl-optimization/44194
> * gcc.dg/pr44194-1.c: New test.
On a bookkeeping note, it doesn't appear that you ever release the
bitmaps for gi->escaped_{p,n} or kill_on_calls. This should probably be
done in dse_step7.
I'm going to assume that you and Richi have agreed upon the form of
can_escape.
AFAICT, even after your patch we still have a wild read recorded for
most CALL_INSNs (see this code in scan_insn which was not modified):
else
/* Every other call, including pure functions, may read memory. */
add_wild_read (bb_info);
It appears that you effectively ignore the wild_read in
scan_reads_nospill by special casing CALL_INSNs. Correct? Is so, does
it make still sense to call add_wild_read in scan_insn?
ISTM that wild reads are still possible due to a few other constructs
such as asms, address canonicalization failure, etc, so why is the
removal of the wild read support in dse_step5_nospill correct?
Just to be clear, I generally like the change, but there's some details
that I think need to be better understood before installing.
jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNtalUAAoJEBRtltQi2kC7evMH/0UyasIBTcZM7MSeCDGvefdR
byd5/XaaH1FtdRS64ne1bGbjB/h96AJbXYfc3QECtKugfmwgSbJeaN/BD8T4WY/L
2z1MkeSwcpswnxufjTR6G5WezuUsxagB4/xoSqk7NRfJdsM3eBR9n+ehTwlfsU5q
bTvQ/Uat0x027ddyrifD6vIOIIqFwMba9CvvN7vV0O+yzuxjzxNfe4IEcyMg2RIZ
j6xK+Bv7pge9pHC8ERKOFO17CPdK2JBe4ovtFL8s1sadBkjO2044uRszcl8E/9rj
MUGHExtFEIypzzi0wBqWyy3fz5QRCBuN/Xj6ptk4Cw7dkuBTZPWjySWrXV5kEs4=
=omzC
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2011-04-25 17:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-22 21:44 Easwaran Raman
2011-04-22 21:49 ` Jakub Jelinek
2011-04-22 22:16 ` Easwaran Raman
2011-04-25 17:21 ` Jeff Law [this message]
2011-04-26 22:31 ` Easwaran Raman
2011-05-03 3:38 ` Jeff Law
2011-05-03 10:10 ` Richard Guenther
2011-05-03 16:41 ` Easwaran Raman
2011-05-10 20:49 ` Easwaran Raman
2011-06-14 17:09 ` Jeff Law
2011-06-17 22:44 ` Easwaran Raman
2011-06-18 19:34 ` Easwaran Raman
2011-06-20 11:14 ` Richard Guenther
2011-06-15 3:53 ` H.J. Lu
2011-06-15 16:37 ` Easwaran Raman
2011-06-18 10:32 ` Ramana Radhakrishnan
2011-06-20 15:34 ` Jeff Law
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=4DB5A955.7030400@redhat.com \
--to=law@redhat.com \
--cc=eraman@google.com \
--cc=gcc-patches@gcc.gnu.org \
--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).