public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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-----

  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).