Re: add h8sx support to h8300

[Alexandre Oliva <aoliva@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}