From: Olivier Hainque <hainque@ACT-Europe.FR>
To: Richard Henderson <rth@redhat.com>, Jan Hubicka <jh@suse.cz>,
Michael Matz <matz@suse.de>,
gcc@gcc.gnu.org
Cc: hainque@ACT-Europe.FR
Subject: Re: Question on fixup_abnormal_edges
Date: Wed, 16 Oct 2002 02:58:00 -0000 [thread overview]
Message-ID: <20021016093134.A12302@berlin.int.act-europe.fr> (raw)
In-Reply-To: <20021015230235.GM25225@redhat.com>; from rth@redhat.com on Tue, Oct 15, 2002 at 04:02:35PM -0700
First of all, thanks for your replies.
Michael Matz wrote:
> Abnormal edges are only used to prevent STACK_REGS from
> being allocated to such pseudos, similar to what global.c is doing.
Indeed.
Richard Henderson wrote:
> Well, except for caller-save not being intelligent enough to
> add the instruction to the edge, rather than directly after
> the call instruction, everything would have worked out ok.
Yes.
> Off-hand I don't know caller-save well enough to know how easy
> it would be to (1) fix this or (2) disable allocation of call
> clobbered hard regs to pseudos live across ABCALL/EH edges.
OK.
Two questions to help me understand the problem further:
o register allocation already has tests to prevent allocations
for pseudos live across calls when current_function_has_nonlocal_label.
This makes a significant difference in policy between setjmp/longjmp and
table driven EH. Was this intended in the first place ?
o fixup_abnormal_edges already cleans up after caller-save, and could
perhaps also do the job.
So far, it searches for a FALLTHRU edge out of the block and moves the
insns there.
Was there a specific reason for not adding them to the abnormal edge
also ?
next prev parent reply other threads:[~2002-10-16 7:31 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-01 2:06 Olivier Hainque
2002-10-01 2:08 ` Jan Hubicka
2002-10-01 2:57 ` Olivier Hainque
2002-10-01 3:00 ` Michael Matz
2002-10-01 3:03 ` Michael Matz
2002-10-01 3:40 ` Olivier Hainque
2002-10-01 4:23 ` Jan Hubicka
2002-10-01 6:49 ` Olivier Hainque
2002-10-01 7:02 ` Jan Hubicka
2002-10-01 7:08 ` Olivier Hainque
2002-10-01 7:12 ` Jan Hubicka
2002-10-01 8:44 ` Olivier Hainque
2002-10-01 9:08 ` Jan Hubicka
2002-10-01 9:46 ` Olivier Hainque
2002-10-01 12:24 ` Michael Matz
2002-10-02 14:11 ` Olivier Hainque
2002-10-03 6:20 ` Jan Hubicka
2002-10-03 6:26 ` Olivier Hainque
2002-10-03 6:51 ` Jan Hubicka
2002-10-03 8:06 ` Olivier Hainque
2002-10-03 8:19 ` Jan Hubicka
2002-10-15 5:35 ` Olivier Hainque
2002-10-15 17:03 ` Richard Henderson
2002-10-16 2:58 ` Olivier Hainque [this message]
2002-10-16 4:02 ` Michael Matz
2002-10-16 4:06 ` Jan Hubicka
2002-10-16 4:45 ` Michael Matz
2002-10-16 5:01 ` Jan Hubicka
2002-10-16 10:29 ` Richard Henderson
2002-10-16 10:26 ` Richard Henderson
2002-10-01 4:43 ` Michael Matz
2002-10-01 4:46 ` Jan Hubicka
2002-10-15 6:10 Richard Kenner
2002-10-15 7:47 ` Michael Matz
2002-10-15 9:25 ` Michael Matz
2002-10-16 0:31 Richard Kenner
2002-10-16 2:31 ` Richard Henderson
2002-10-16 7:08 Richard Kenner
2002-10-21 11:50 ` Jeff Law
2002-10-21 11:54 ` David S. Miller
2002-10-16 7:12 Richard Kenner
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=20021016093134.A12302@berlin.int.act-europe.fr \
--to=hainque@act-europe.fr \
--cc=gcc@gcc.gnu.org \
--cc=jh@suse.cz \
--cc=matz@suse.de \
--cc=rth@redhat.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).