From: Kenneth Zadeck <zadeck@naturalbridge.com>
To: Jan Hubicka <jh@suse.cz>
Cc: Kenneth Zadeck <Kenneth.Zadeck@NaturalBridge.com>,
gcc-patches@gcc.gnu.org, "Bonzini, Paolo" <bonzini@gnu.org>,
Kaz Kojima <kkojima@rr.iij4u.or.jp>
Subject: Re: RTL sharing tester (for testing)
Date: Thu, 28 Jun 2007 19:57:00 -0000 [thread overview]
Message-ID: <46840F26.8090900@naturalbridge.com> (raw)
In-Reply-To: <20070628171601.GF5913@kam.mff.cuni.cz>
Jan Hubicka wrote:
>>>>> Then the above error on SH went away. This one liner may be
>>>>> an overkill, but I hope that this experiment will help experts
>>>>> to narrow down the problem.
>>>>>
>>>> Actually this seems like a correct fix for me. In fact I was just
>>>> looking into instance of identical problem on PPC bootstrap (different
>>>> file, same directory of libjava :). We will copy iff the reg actually
>>>> is subreg and in that case we are required to copy.
>>>>
>>> Ok, but please let Jan run it thrugh your memory tester first. (Jan, it
>>> may actually be best if you commit it in place of Kaz).
>>>
>>> Paolo
>>>
>> Three things:
>>
>> (1) I think I would like to get some input from a middle-end
>> maintainer or a gwm before this patch goes in. This seems like a very
>> heavy handed solution to this problem. This is going to chew up the
>> memory.
>>
>
> The users of df_set_note all just take the registers from dataflow
> information and call the function to produce REG_DEAD/REG_UNUSED notes.
> This all is going to introduce invalid sharing for subregs in all cases
> and if we are going to produce the note with SUBREG, we simply must
> produce the copy. (If we are very very cautious, we probably can have
> some cache since we are probably recomputing those notes quite often,
> but I doubt it is worth the extra complexity and we can see it easilly
> from memory tester)
>
>
Yes, i think that you are right. i was thinking that this was called
when eq_notes were changed. Because of this mistake on my part,
everything I said in this mail is suspect.
> Note that copy_rtx does nothing for REG, since registers are shared, so
> it should not be overly expensive and we simply must produce the
> duplicate for the case of SUBREG or any other unshared RTL expression.
>
> However I now wonder why do we want to see subregs there at all.
> Originally I assumed that we now do partial liveness for multiple word
> values, but it is not the case. Perhaps the right thing to do is to
> simply strip away the SUBREG and keep only the REG itself?
> At least before dataflow, I don't think we produced SUBREGs in those
> notes, I might be wrong.
>
>>
>> (2) Kaz, one trick that you can try is to back out this
>> patch and instead put a call to verify_rtl_sharing right after the
>> assignment of REG_NOTES in df_set_note.
>>
>> /* Did not find the note. */
>> REG_NOTES (insn) = alloc_EXPR_LIST (note_type, reg, REG_NOTES (insn));
>> verify_rtl_sharing ();
>> return old;
>>
>> This will cause a failure when the shared note is inserted in the
>> stream. If you get into the debugger, the stacktrace should land you
>> exactly at the place where the shared note is being inserted.
>>
>> (3) Paolo, I tried the trick in (2) on pr32372 and it did not help.
>> The reason is that the sharing in cse1 is caused by cse is taking
>> something out of a reg_equal note and replacing an insn with it
>>
>
> My method of handling those problems is to simply put verify_rtl_sharing
> now and then into the cse_insn spagetti function. Usually the
> backtrace from gdb allows quickly to pinpoint the problematic
> transformation.
>
> Honza
>
>> Kenny
>>
next prev parent reply other threads:[~2007-06-28 19:42 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-26 3:43 Jan Hubicka
2007-06-27 15:55 ` Kenneth Zadeck
2007-06-27 18:17 ` Diego Novillo
2007-06-27 21:43 ` Jan Hubicka
2007-06-28 2:02 ` Kaz Kojima
2007-06-28 4:24 ` Jan Hubicka
2007-06-28 8:11 ` Paolo Bonzini
2007-06-28 17:16 ` Kenneth Zadeck
2007-06-28 18:26 ` Jan Hubicka
2007-06-28 19:57 ` Kenneth Zadeck [this message]
2007-06-28 20:27 ` Richard Sandiford
2007-06-29 8:29 ` Richard Sandiford
2007-06-29 12:11 ` Kenneth Zadeck
2007-06-29 13:35 ` Paolo Bonzini
2007-06-29 13:37 ` Bernd Schmidt
2007-06-29 13:39 ` Jan Hubicka
2007-06-29 16:55 ` Richard Sandiford
2007-07-13 10:15 ` RFA: Stop df from generating SUBREG REG_NOTES Richard Sandiford
2007-07-25 22:50 ` Richard Sandiford
2007-07-27 0:01 ` Ian Lance Taylor
2007-06-28 20:19 ` RTL sharing tester (for testing) Paolo Bonzini
2007-06-27 23:06 ` Mark Mitchell
2007-06-27 23:06 ` Jan Hubicka
2007-06-27 23:12 ` Eric Christopher
2007-06-28 0:48 ` Jan Hubicka
2007-06-28 22:24 ` Eric Christopher
2007-06-29 23:14 ` Graham Stott
2007-06-30 0:17 ` Jan Hubicka
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=46840F26.8090900@naturalbridge.com \
--to=zadeck@naturalbridge.com \
--cc=Kenneth.Zadeck@NaturalBridge.com \
--cc=bonzini@gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jh@suse.cz \
--cc=kkojima@rr.iij4u.or.jp \
/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).