Re: How to clean up i386 machine description?

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

  In message <199811060946.BAA24434@Sunburn.Stanford.EDU>you write:
  > Over the past two weeks I have been trying to familiarize myself with
  > the x86 machine description by going through the file and documenting
  > what machine instructions were generated for each pattern under what
  > circumstances.  This grew a bit tedious after a while; I got about 25%
  > through the file before I figured I was spending too much time on
  > this.  (Not that it was a bad thing to do, but at the rate I was going
  > it would have taken me two months to finish!)  So right now I'm most
  > familiar with test, compare, and move patterns.  Alas, these may not
  > be the best patterns for a newbie to work on.  Oh well.
Test, compare and move patterns are important.  Jan has already started on
the move patterns.

  > As I asked in another message, it would be nice to know which ports
  > are considered to be up-to-date in this respect, so as to provide a
  > good model for cleaning up the others.
alpha, rs6000, hppa would be worth looking at.  You may also want to peek
at the mn102 and mn103 for risc-like ports with small register sets.

  > So do you think it might be best for me to first work on tightening
  > predicates where possible?  I've asked Jan about possibly doing this
  > in another message.  It would be interesting to see how much gain we
  > could get simply from this.
Yea.  It's definitely one of several steps that's worth doing.

  > I agree with you on selecting the easier ones first.  To me this means
  > doing integer instructions first, since the x86 floating-point model
  > is peculiar.  The register stack complicates things, and the
  > condition-code handling will need major changes to be supported
  > properly.  Also there are lots of issues with precision loss and IEEE
  > compliance when generating floating-point code.
Agreed.  Go integer first.

  > By the way, which version of the code should I use to test prospective
  > changes?  Obviously the current CVS snapshot is best to stay
  > compatible with current work, and any submitted patches should be made
  > against that tree, but I haven't used CVS yet; I've been downloading
  > the weekly snapshots instead.  (How well do updates from CVS work over
  > a modem link?)  And the latest snapshot (19981101) won't even
  > bootstrap properly with normal build flag settings on my machine; I
  > get the often-reported fini-segfault failure.  If the current sources
  > are that unstable right now, maybe it would be better to test changes
  > with an older, more stable tree?  On the other hand, I should
  > definitely test any changes with Bernd's new reload code.  Decisions,
  > decisions...
I'd recommend working with CVS -- it's easier to coordinate when multiple
folks start working on the code.  It also makes patch submission easier.

CVS works fine over a modem.  In fact, I'm using it over a 33.6 modem
right now :-)  Make sure you turn on compression (cvs -z 9 <command>).

We're working to restablilize the cvs tree -- it's been more unstable than
I'd like -- it's effecting the ability of developers to work.  I expect the
current instability to settle down soon.

jeff