From: Jan Hubicka <jh@suse.cz>
To: Kenneth Zadeck <Kenneth.Zadeck@NaturalBridge.com>
Cc: gcc-patches@gcc.gnu.org, jh@suse.cz, "Bonzini,
Paolo" <bonzini@gnu.org>, Kaz Kojima <kkojima@rr.iij4u.or.jp>,
zadeck@naturalbridge.com
Subject: Re: RTL sharing tester (for testing)
Date: Thu, 28 Jun 2007 18:26:00 -0000 [thread overview]
Message-ID: <20070628171601.GF5913@kam.mff.cuni.cz> (raw)
In-Reply-To: <87hcosdoqc.fsf@moria.site>
> >>> 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)
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 17:16 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 [this message]
2007-06-28 19:57 ` Kenneth Zadeck
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=20070628171601.GF5913@kam.mff.cuni.cz \
--to=jh@suse.cz \
--cc=Kenneth.Zadeck@NaturalBridge.com \
--cc=bonzini@gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=kkojima@rr.iij4u.or.jp \
--cc=zadeck@naturalbridge.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).