Re: How to clean up i386 machine description?

[Jan Hubicka <hubicka at horac dot ta dot jcu dot cz>]

> 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?
Well :) I am playing with many patterns so I am really not sure :)
I should send you my patche md files so you might look how situation looks
like.
>From predicates point of view:
Some changes I've already sent to egcs-patches, but I need to solve
problem with floating point predicates before it should be checked in.
I've also made separate patterns for shift by 1, incrementation and decrementation,
DI mode shifts, sign extensions, divmod patterns, almost all FP patterns.
Rest of them are almost untoched..
> 
> 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
Well, current FP patterns with some fiddling behaves very well when
compared to other compilers on Pentium. Better support for non-pipelined
FPU units should require completely different reg-stack pass and
that should need redesign of FP code in i387. But otherwise it don't
do so bad job.
> 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.  :-)
Well actually bigger problem is getting extra precision :)
> 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

The cc0 model don't work so well for x86 at all. I am thinking about
rewriting it. It should let us to model both cc registers and improve
scheduling because insns not affecting cc0 (leas, movs) should be moved
around w/o any restrictions.
Once patterns are cleanner I.E you might see easily what instrucntions will
be at output I believe it should be quite easy change. Just to add two
new registers and write clobbers where neccesary.
But I am not sure how big advantage it is. There is lots of other issues
that should improbe code much more.


Honza