Re: How to clean up i386 machine description?

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

Jan Hubicka writes:
> 
> > 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.

> Thats one of the problems. I've split many of them but at other I am
> getting surprisingly large amout of problems and implementation details.
> I've spent over a week by playing with divmod patterns and I still don't
> have solution that satisfies me (I.E generates supperior code to all other
> implementations I know of)
> Many expands and splits ssuggest changes to generic code and so on,
> so it is probably long progress. But I would welcome if someone should
> work with me at this work. I think developing changes complettely separately
> should tend to large dupplication of work, so until major parts of my changes
> are accepted to egcs (hope this will be soon, since copyright issues are
> "amost solved :))", please let me know about your ideas and changes
> you want to do.

I'd be happy to work with you, although at this point I'm not sure
where to begin.  One obvious thing to try is Jeff's suggestion to
tighten up operand predicates so that they closely correspond with the
reload constraints.  I understand you've already done some of that.
Is there a set of instructions you're not working with, so that we
don't overlap?

Unfortunately the only patterns I've examined in detail so far are the
test, compare, and move patterns, simply because they came first in
the machine description.  None of these are the best choice for a
newbie; the tests and compares interact with conditional branches and
sets, and I need to understand that interaction better before working
with them.  Moves are fundamental to the operation of reload, and it
may be that they require looser predicates than most other instruction
patterns.

I think for me it would be best to work with integer instructions for
now.  The x86 floating-point model is rather peculiar and supporting
it efficiently in gcc might require major changes to the machine
description.  Not to mention that you have to be very careful with
floating-point optimizations so that you don't end up losing precision
in the name of speed.  We don't need a gcc equivalent of the Pentium
bug fiasco, and I don't relish the thought of answering to a horde of
angry numerical analysts.  :-)

> Other tricky part is probably 387 support. Splitting insns is almost
> impossible here, since in final part you need to take care for
> REG_DEAD_NOTES.  I am thinking about final splitting insns _before_
> reg-stack pass to avoid this problems (this should help a
> lot). Other helpfull think is probably to pass insn parametter to
> splits, so split should look for notes and context. This should let
> me to implement working fsincos patterns.
> 
> Other large problem are 387 conditions. They generate large sequence of
> insns with relatively large latencies. Problem is that they can not be
> well represented by RTL, so I have to think about this a bit.

Yes, I noticed those were particularly nasty.  It looks to me like the
cc0 model doesn't work well for x86 floating-point conditions, since
the FPU effectively has its own condition code register, the contents
of which must be moved to the integer unit to do most conditional
operations.  It's not clear to me what the best way to describe this
is, but I presume that we'll eventually need to define a special hard
register for floating-point condition codes.

> > 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?
> 
> There is many details. Sometimes the contrstrains are too benevolent
> and instruction pattern do thinks, that should be easily (and more
> eeffectivly IMO) done by generic code. One example is conversion of
> integer regs to fp, that is done by pushing onto stack and popping
> back.  Simple extension to reload pass I've suggested in one of
> other emails should improve code in this case.

Yes, I've noticed that too.  The use of integer registers in the
constraints of floating-point instructions, causing lots of extra
moves to and from the stack, struck me as particularly nonproductive.

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