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

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