Re: How to clean up i386 machine description?

[Colin Douglas Howell <howell at cs dot stanford dot edu>]

Jeffrey A Law writes:
> 
> 
>   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.

Well, I'm ambitious, but this sounds like good advice.

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.

>   > 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 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.

>   > 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.

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.

>   > 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.

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.

As for which integer instructions, I think it might be best to do
general integer operations first.  As I said, I've only looked closely
at test/compares and moves so far, but test/compares interact closely
with conditional branches and sets, and moves are very important for
reload, so these aren't exactly the simplest things to hack on.

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...

> 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 :-)

Still haven't done this.  Ugh.

-- 
Colin Douglas Howell                    Systems Administrator
e-mail:  howell@cs.stanford.edu         Computer Facilities Group
office:  (650) 723-2491                 Computer Science Department
                                        Stanford University