Re: How to clean up i386 machine description?

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

  In message <19981026203605.C25151@dot.cygnus.com>you write:
  > Running a very close second in importance is to give the scheduler
  > an accurate description of how the instruction to be emitted should
  > be scheduled.  It does little good to tell the scheduler that the
  > instruction is of one type when for some case something entirely
  > different is emitted. 
Very true.  One of the other major problems in the x86 port.

  > One of Jan's patches attempts to add issue information for the
  > pentium to the paterns.  However, the approach he took is not
  > particularly accurate, and I fear not to be scalable to even 3 
  > ia32 variants -- there are probably at least 7 extant now, and
  > more to come.  I hadn't had the heart to tell Jan eariler, since
  > I didn't know what to do about it.
Same as we're doing elsewhere, only uglier.  Instead of using constraints to
drive reload, use them to drive attribute characteristics.  It's not going to
be pretty though.


  > As a consequence of a bit of nagging from some quarters, I've been
  > thinking about this a lot recently.  The only way I can see to get
  > this right is to move all of the final instruction selection logic
  > out of the large output code blocks, and put it somewhere visible
  > to the scheduler -- namely, tied to attribute type.  Furthermore,
  > the instruction output patterns must be based exclusively on the
  > external selection code.  Otherwise we can't prove convergance and
  > will have lost out on that hard work.
Yup.

  > This is a huge amount of work, amounting to a near complete rewrite
  > of the .md file.  I can't see that anything less will result in
  > anything other than mass confusion though.
Yup, and that's precisely what we're going to need to do in the end...  The
x86 port just was never written with a scheduler in mind.  Converting it to
be scheduler aware is going to be a major pain in the ass.

jeff