Re: How to clean up i386 machine description?

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

  In message <199810251818.KAA02869@Sunburn.Stanford.EDU>you write:
  > I've been spending the last several weeks reading the gcc internals
  > manual and browsing through the code to get more of a handle on how
  > the EGCS back end works.  At this point I think I have a pretty good
  > general grasp of it, although of course there are many details I am
  > still ignorant of.
That's OK.  You figure out the details as you go along.  I've been hacking gcc
for nearly 10 years and there's still many things I don't know.  Don't expect
to learn it all.  Instead learn everything you need to so that you can deal
with a particular issue.

  > been looking at the x86 machine description itself.  It looks ugly, to
  > say the least, and needs a lot of cleaning up.
Yes.  It needs a major cleanup.  Actually, I would say that's the case for all
of our old cisc ports and some of our older risc ports.  Over time we learn
what works well and what doesn't and we need to apply that knowledge to some of
the older ports.

  > As you said in a
  > thread started by one of Jan's messages, many insns are output as a
  > series of machine instructions; this must be fixed in order to
  > schedule instructions effectively.
Yes.  This is one of the most critical issues for scheduling.  If done
correctly we may also be able to improve the reloading aspects of the x86 port.

In addition to outputting many insns, the x86 port relies on reload to clean
things up.  ie, it has predicates which are very general and relies on reload
to move operands around to make them match the constraints.

Bernd's reload work helps this problem by making the cost to spill a register
much smaller, but it's been my experience that generally better code is
achieved by writing tighter predicates.


  > I've just scratched the surface of the x86 machine description; I
  > still have a lot to read.  Besides the problem of single insns being
  > output as multiple instructions, do you have any ideas on how best to
  > go about fixing the description?  What would you say needs to be done
  > first?
Well, there's two schools of though.  Go after the easy ones first, or go after
those which give you the most benefit first.  Since this is your first hacking
experience in gcc, I'd select the former.

The next decision is how to split them up.  Is it better to use a define_split
to have the scheduler break up the complicated insn into simpler insns?  Or is
it better to tighten the predicates and possibly have multiple insns for the
various conditions?  I don't know.  It kind of depends on the complexity of the
pattern you're working with.  I don't know the x86 port well enough to make
suggestions on this one.

  > Also, I'm wondering about Jan's patches.  None of them seem to have
  > gone into the CVS tree yet.  Is there a holdup on the copyright
  > assignment form, or some other problem?
They were held up on copyright issues.  I just checked the FSF copyright list
and Jan's copyright assignment has been filed.  So I guess we need to look at
his patches more closely now :-) :-)

  > Speaking of that form, I'm going to have to submit one myself if I'm
  > going to do any real work on EGCS.  I currently work for Stanford
  > University; does anyone know if there are other issues which must be
  > settled to prevent Stanford trying to lay claim to any work I do?
  > (Not that Stanford is really bad on this score, but this should be
  > cleared up.)
You may need to get someone at Standford to sign an employer disclaimer  A
copy of the employer disclaimer can be found on the web site too (in the
assignment instructions I believe).  We rarely have problems getting an
employer to sign the disclaimer since it's very specific about what they're
signing away :-)

jeff