From: Alexandre Oliva <aoliva@redhat.com>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: Kazu Hirata <kazu@cs.umass.edu>, gcc-patches@gcc.gnu.org
Subject: Re: add h8sx support to h8300
Date: Thu, 08 Jul 2004 21:20:00 -0000 [thread overview]
Message-ID: <oru0wimfes.fsf@free.redhat.lsd.ic.unicamp.br> (raw)
In-Reply-To: <873c42e8rb.fsf@redhat.com>
On Jul 8, 2004, Richard Sandiford <rsandifo@redhat.com> wrote:
> Alexandre Oliva <aoliva@redhat.com> writes:
>>> I tried the attached, both with and without the h8300.md bit,
>>> and it didn't make any difference to the results for this testcase.
>>> Like you say, -O3 -fomit-frame-pointer fails either way.
>>
>> Right. But lower optimization levels failed before the patch, and
>> passed with it.
> But my point is that the testcase passes at the other optimisation
> levels even if the patch I attached is applied.
Anyhow, whether the testcase passes with your patch or not is not very
relevant. Using !D at that point is wrong, for the reasons explained
in the comments.
! prevents reload from even considering an alternative. So, given
`d,!D', if it couldn't satisfy the constraint in local or global
alloc, it will require r6 (or, worse, NO_REGS, if `d' happens to
expand differently) during reload. NO_REGS will obviously be
impossible to satisfy, and r6 may be impossible to satisfy if the
frame pointer is found to be needed during reload (this happens in
builtin-apply2).
So we absolutely need another way to represent that. d,??D is
probably not it, because reload will sometimes still choose the first
alternative and die upon the impossibility of spilling r6 because the
frame pointer became needed.
I'm certainly open to change, but !D is not the way to go. It's wrong
in theory, even if in practice it appears to work. I.e., as the
compiler gets smarter, it will break.
I could think of a few solutions that were probably worth trying, but
I ran out of time before I could implement them:
- introduce another virtual register, and use that as an alternative
to `d', and then have a machine-dependent pass that `reloads' that
into r6 as needed.
- somehow give r6 a higher priority in being chosen to satisfy an `D'
constraint, and force `d' to match before reload.
- add another scratch register and hope it gets r6 if it's available
at all, and use that to save/restore r6 otherwise
- emit save r6, movmd with r6 referenced as an output hardware
register, copy r6 elsewhere, restore r6 explicitly, and then
optimize away the save and restore if it turns out that we got r6.
Must somehow make sure reload doesn't emit output reloads that
reference the modified r6. Yuck.
Yeah, not an easy problem :-(
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
next prev parent reply other threads:[~2004-07-08 20:07 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-21 14:24 Alexandre Oliva
2004-06-21 17:12 ` Kazu Hirata
2004-06-23 2:23 ` Alexandre Oliva
2004-07-07 22:11 ` Alexandre Oliva
2004-07-08 6:08 ` Richard Sandiford
2004-07-08 7:41 ` Alexandre Oliva
2004-07-08 9:39 ` Richard Sandiford
2004-07-08 18:16 ` Alexandre Oliva
2004-07-08 18:16 ` Richard Sandiford
2004-07-08 20:23 ` Alexandre Oliva
2004-07-12 20:14 ` Richard Sandiford
2004-07-14 12:49 ` Alexandre Oliva
2004-07-14 17:16 ` Richard Sandiford
2004-07-15 4:11 ` Alexandre Oliva
2004-07-15 5:22 ` Richard Sandiford
2004-07-15 16:25 ` Alexandre Oliva
2004-07-15 17:14 ` Richard Sandiford
2004-07-15 17:25 ` Richard Sandiford
2004-07-15 22:23 ` Alexandre Oliva
2004-07-08 21:20 ` Alexandre Oliva [this message]
2004-07-06 20:56 ` Alexandre Oliva
2004-07-07 2:37 ` Richard Henderson
2004-07-07 7:06 ` Alexandre Oliva
2004-07-07 9:06 ` Richard Henderson
2004-07-08 0:14 ` Alexandre Oliva
2004-07-08 1:22 ` Richard Henderson
2004-07-08 1:26 ` Alexandre Oliva
2004-07-08 2:01 ` Richard Henderson
2004-07-08 4:39 ` Alexandre Oliva
2004-07-08 18:59 ` Alexandre Oliva
2004-07-07 9:13 ` Joseph S. Myers
2004-07-07 19:44 ` Alexandre Oliva
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=oru0wimfes.fsf@free.redhat.lsd.ic.unicamp.br \
--to=aoliva@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=kazu@cs.umass.edu \
--cc=rsandifo@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).