public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "nvachhar at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/40209] ICE in iv_analyze_def caused by stale REG_UNUSED note
Date: Fri, 24 Jul 2009 17:47:00 -0000	[thread overview]
Message-ID: <20090724174742.7741.qmail@sourceware.org> (raw)
In-Reply-To: <bug-40209-17188@http.gcc.gnu.org/bugzilla/>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3707 bytes --]



------- Comment #7 from nvachhar at google dot com  2009-07-24 17:47 -------
Subject: Re:  ICE in iv_analyze_def caused by 
        stale REG_UNUSED note

This looks reasonable to me.  Given the caveats you mention in the
comment, this would need to be tested for correctness (esp. w.r.t. the
newly added registers) and obviously would need to be tested for
performance regressions.

On Fri, Jul 24, 2009 at 5:04 PM, steven at gcc dot gnu dot
org<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #6 from steven at gcc dot gnu dot org  2009-07-24 17:04 -------
> Then we should write a new function, something like this in df.h perhaps:
>
> /* Given an INSN, return a SET expression if the insn has only one
>   SET whose SET_DEST is used.  If SET_DEST is memory, then the SET is
>   assumed to be used somewhere, always.
>
>   This means that:
>   * If an insn has multiple SETs to only registers, but only one of those
>     SETs is used, return that one set.
>   * If an insn has multiple SETs to only registers, but none one of those
>     SETs is used, return NULL_RTX.
>   * If an insn has multiple SETs to registers and/or memory, but the SETs to
>     registers are dead, return the one memory SET, or NULL_RTX if there are
>     multiple sets to memory.
>
>   Only accept INSNs.  single_set() can take a pattern, but that is
>   "old skool" style that should be abolished.
>
>   May miss some single_set SETs that single_set() can find, because this
>   function just looks for the number of uses of a register to determine
>   whether a set is used (which may fail for hard registers and for unusual
>   situations with pseudos that somehow are set twice but never used) whereas
>   single_set() uses liveness information through REG_UNUSED notes.  Still,
>   I expect that, in practice, this function works just as well as
>   single_set().
>
>   One more caveat: The DF user must use incremental scanning, or the
>   DF_REG_USE_COUNT may be wrong.  The result of df_single_set would be
>   unconservative for new registers since the last scan (DF_REG_USE_COUNT
>   will still be 0, indicating the new reg is unused and its SET can be
>   ignored).  */
>
> rtx
> df_single_set (rtx insn)
> {
>  rtx pat;
>
>  gcc_assert (INSN_P (insn));
>
>  /* ??? Could even just fall back if the current DF mode is not incremental
>         scanning.  */
>  pat = PATTERN (insn);
>  if (GET_CODE (pat) == SET)
>    return pat;
>  else if (GET_CODE (pat) == PARALLEL)
>    {
>      int i;
>      rtx set = NULL_RTX;
>      for (i = 0; i < XVECLEN (pat, 0); i++)
>        {
>          rtx sub = XVECEXP (pat, 0, i);
>          switch (GET_CODE (sub))
>          {
>          case USE:
>          case CLOBBER:
>            break;
>
>          case SET:
>            if (! set)
>              {
>                rtx dest = SET_DEST (set);
>                if (GET_CODE (dest) == SUBREG)
>                  dest = SUBREG_REG (dest);
>                if (! REG_P (dest)
>                    || DF_REG_USE_COUNT (dest) > 0)
>                  set = sub;
>              }
>            else
>              return NULL_RTX;
>            break;
>
>          default:
>            return NULL_RTX;
>          }
>        }
>    }
>  else
>    return NULL_RTX;
> }
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209


  parent reply	other threads:[~2009-07-24 17:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-20 18:47 [Bug rtl-optimization/40209] New: ICE in iv opts " nvachhar at google dot com
2009-05-20 18:49 ` [Bug rtl-optimization/40209] " nvachhar at google dot com
2009-07-24  4:01 ` [Bug rtl-optimization/40209] ICE in iv_analyze_def " ian at gcc dot gnu dot org
2009-07-24  6:25 ` ubizjak at gmail dot com
2009-07-24  6:27 ` steven at gcc dot gnu dot org
2009-07-24 15:39 ` nvachhar at google dot com
2009-07-24 17:05 ` steven at gcc dot gnu dot org
2009-07-24 17:47 ` nvachhar at google dot com [this message]
     [not found] <bug-40209-4@http.gcc.gnu.org/bugzilla/>
2023-12-06 18:32 ` pinskia at gcc dot gnu.org
2023-12-06 18:33 ` pinskia at gcc dot gnu.org

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=20090724174742.7741.qmail@sourceware.org \
    --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).