public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Xionghu Luo <luoxhu@linux.ibm.com>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	jakub@redhat.com, bonzini@gnu.org, ebotcazou@gcc.gnu.org,
	abel@gcc.gnu.org
Subject: Re: CSE deletes valid REG_EQUAL?
Date: Mon, 16 Nov 2020 18:12:03 -0700	[thread overview]
Message-ID: <be404792-19ab-e0b4-5e6b-4160a778acf1@redhat.com> (raw)
In-Reply-To: <20201113135516.GU2672@gate.crashing.org>



On 11/13/20 6:55 AM, Segher Boessenkool wrote:
> Hi guys,
>
> On Thu, Nov 12, 2020 at 09:10:14PM -0700, Jeff Law wrote:
>> On 11/12/20 7:02 PM, Xionghu Luo via Gcc wrote:
>>> The output shows "REQ_EQUAL r118:DI+0x66546b64" is deleted by df_remove_dead_eq_notes,
>>> but r120:DI is not REG_DEAD here, so is it correct here to check insn use and find that
>>> r118:DI is dead then do the delete?
>> It doesn't matter where the death occurs, any REG_DEAD note will cause
>> the REG_EQUAL note to be removed.  So given the death note for r118,
>> then any REG_EQUAL note that references r118 will be removed.  This is
>> overly pessimistic as the note may still be valid/useful at some
>> points.  See
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92291
> The note even *always* is valid where it is!  As you say, the REG_EQUAL
> is only (necessarily) valid at *that* insn.  And this insn *sets* the
> reg (that is the only case when a REG_EQ* is allowed at all), so if the
> eq reg is dead (i.e. unused) the whole insn is, and the insn can be
> removed.
>
> Removing all REG_EQUAL notes for regs that become dead anywhere seems
> to just be a thinko?  All pseudos are dead somewhere!  (Yeah okay,
> infinite loops, but other than that.)
Yea, but the code which wipes the notes probably has no sense of where
in the RTL stream the note is valid and where it is not.  So it does the
fairly dumb thing and just ends up wiping them all away because as you
noted, most pseudos have a death somewhere.  One might argue that the
code is OK as-is, but just needs to be run later.  After cse2 would be
the most logical location since CSE is probably the heaviest user of the
notes.  But I'd worry that the problems referenced in c#2 of bz51505
could crop up in other contexts than just combine.

jeff



  reply	other threads:[~2020-11-17  1:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13  2:02 Xionghu Luo
2020-11-13  4:10 ` Jeff Law
2020-11-13 13:55   ` Segher Boessenkool
2020-11-17  1:12     ` Jeff Law [this message]
2020-11-17  8:57       ` Paolo Bonzini

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=be404792-19ab-e0b4-5e6b-4160a778acf1@redhat.com \
    --to=law@redhat.com \
    --cc=abel@gcc.gnu.org \
    --cc=bonzini@gnu.org \
    --cc=ebotcazou@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=luoxhu@linux.ibm.com \
    --cc=segher@kernel.crashing.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).