Re: hard register reload patch

[Jeffrey A Law <law at cygnus dot com>]

  In message <199911301826.SAA19488@phal.cygnus.co.uk>you write:
  > This is muddy, too.  What is a copy?  On some hardware, signe and/or zero
  > extension is part of a move insn.
  > 
  > And yet this rule is too strict because it would disallow using a hard
  > register where one is naturally used - where you have and insn that
  > can take only one particular register as one of its inputs.  If you accept
  > a pseudo in this place, cse/gcse/loop/combine get taken away and create
  > code that would need dozens of these one-of-a-kind registers to be live
  > simulatanously to avoid lots of reloads.
I agree with Joern here.  We don't want to overly restrict the ways hard
registers can appear.  At least that's my gut feeling.  But to do that we
need to be much smarter about how we transform RTL.  Otherwise we end up
dumping S_R_C hack after hack into the compiler and to me that's just silly.

  > But this is ignoring the fact that the current shunning of explicitly
  > mentioned registers is pessimizing patterns that use them.  And my patch
  > aims to fix that.
  > Moreover, I am not certain that the code you used is sufficiently
  > representative of performance and size critical code on the SH to
  > make the meansurements meaningful.
Given my experiences with this kind of stuff and the maintainability issues,
I *strongly* believe that Bernd's suggestions are the right suggestions.  IMHO
the SH port is a maintainability problem, this is a prime example of the kind
of issue that makes it a maintainability problem.


  > > >   > reg_rtx field set, and it is equal to the in or out field, or to bo
  > th.
  > > > ?!? Can't we tell by the reload type?  Or maybe it would be better to h
  > ave a
  > > > flag which indicates that this is a hard reload.
  > 
  > I though about that, but it doesn't seem to make sense from a simplicity
  > standpoint.  Creating lots of new reload types would make reload even
  > more complex.  An extra flag doesn't really buy much, since you still
  > want to know if it's an input, output or input-output hard reload.
You seem to be missing the point about using a flag.  You're suggesting that
we check a variety of independent things that as a whole *might* actually
be a reasonable check for the case we care about.  That to me is a poor
design, hard to maintain and hard for other people to understand.



  > How about this: send me a copy now.  If I think it makes sense, I'll see
  > how it'll integrate with my patch - then we need not worry to document
  > stuff that is going away anyways.  If not, we can discuss it separately.
*Please* do not do this.  This is precisely the kind of thing that gets us
in trouble -- mega patches that have lots of independent pieces that are
are impossible to review.

These issues need to be kept separate.  Please do not join then.  Doing so
will only make it more likely your patch will not get the proper design
and code review it needs in a timely manner.


  > Well, it's part of the live_before/live_after -> live_throughout/dead_or_se
  > t conversion.
  > And that change is needed as a prerequisite for the hard reloads.
Right.  So submit the live_before/live_after stuff *independently* of the hard
reloads stuff.  You've just made the point that both Bernd and I were trying
to make.  You've got a prerequisite patch that everyone thinks is a good
concept -- so let's deal with it *before* dealing with the hard reloads stuff.

jeff