How to clean up i386 machine description?

[Jan Hubicka]

> 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.
I personally no one can really understand to all details
(even to all major thinks in gcc :) so this is not so bad situation..

> been looking at the x86 machine description itself.  It looks ugly, to
> say the least, and needs a lot of cleaning up.  As you said in a

I agree. My goal is still to do optimizations (it is shame that when
gcc has so many generic optimizations they are sometimes wasted by
final pass :)
> 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.

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

In other cases the predicates are too weak and constraints too strong
that stress reload pass.. and so on...
> 
> 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?
It is copyright assignment. I've printed it, sent to RMS, buthe is away
so I've been asked to send it to Cygnus too. I've printed it but probably
forgot to send. I've sent it today.

Honza