Re: egcs-1.1 status

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

  In message <199808230804.IAA09364@ongaonga.chch.cri.nz>you write:
  > Jeffrey A Law writes:
  >  > The problem is that reload can/will silently trash registers holding
  >  > parameters while trying to satisfy reloads for later register loads.
  >  > Note that reloads can be triggers in many non-obvious ways on the x86
  >  > due to the way the machine description was written.
  > 
  > Am I correct in thinking that the x86 machine description relies
  > too heavily on the reload pass to fix things up and that it should
  > use tighter predicates and the extra condition to check for valid
  > operand combinations?
That's part of the problem.  The x86 and m68k ports in particular share
this trait.  They tend to use very loose predicates and depend on the
constraints to direct reload to copy stuff around.

Cleaning this up would help this situation, but would not solve it.



  > I agree with Jeff that, sure the problem is solvable, but to fix it is
  > certainly non-trivial.  A new reload pass is going to break many
  > things faster than it fixes things for a long time to come...
Yup.  Though we should start thinking about ways we can break up the
problem into more managable pieces.

For example, computing the register lifetime data and building the
necessary infrastruture so that we can update it on the fly in
response to reload's actions can be done without actually acting on
that infomation in reload initially.

We could then use that info to drive a better post-reload instruction
splitter.  That would be fairly simple and straightfoward and would
exercise the register lifetime code and incremental update stuff pretty
well.

Then we start trying to tie it into reload trying to deal with simple
cases where the life information allows us to select better reload regs 
and avoid unnecessary spillage.  Continue adding support for using the
life info until we can try to remove SMALL_REGISTER_CLASS support from
reload itself.

Then work on each of the remaining passes to try SMALL_REGISTER_CLASSES
support once and for all.

Just thoughts.  There may be better approaches, but I think we do need
to start looking at breaking the problem down into something more manageable.
Based on past history and my "gut", as long as we continue to look at
this as the "reload rewrite" it likely won't happen.  To have a chance
we've got to tackle one subproblem at a time.

  > I've been slowly working my way through it and have been writing up
  > some notes on how it currently works.  I'm sure other folks must have
  > done likewise.  May I suggest that the first step is to improve the
  > documentation of the reload pass so as to remove some of the mystique.
  > The docs should say what it tries to do, what it does, and what it
  > should do.
Yes.  I've been trying to encourage some folks in Cygnus to work on
the reload documentation, but I haven't pushed hard enough to make an
impact yet.  This is actually the first step.

  > I also imagine that reload probably needs more guidance from the
  > backends as to how to fix a given problem.
Maybe.  Certainly having the backends provide more info about the
most efficient way to deal with a particular reload would be interesting.
jeff