This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: egcs-1.1 status
- To: Michael Hayes <michaelh at ongaonga dot chch dot cri dot nz>
- Subject: Re: egcs-1.1 status
- From: Linus Torvalds <torvalds at transmeta dot com>
- Date: Sun, 23 Aug 1998 11:20:18 -0700 (PDT)
- cc: law at cygnus dot com, Andi Kleen <ak at muc dot de>, "H.J. Lu" <hjl at lucon dot org>, manfred at s-direktnet dot de, Manfred dot Hollstein at ks dot sel dot alcatel dot de, egcs at cygnus dot com
On Sun, 23 Aug 1998, Michael Hayes wrote:
>
> Am I correct in thinking that the x86 machine description relies
> too heavily on the reload pass to fix things up and that it should
> use tighter predicates and the extra condition to check for valid
> operand combinations?
The i386.md file certainly seems to break the register allocator more
easily than it should - there's been various "impossible pattern" bugs
that are fairly easy to introduce by mistake when you expect too much of
reload. A few patterns seem to be disabled because nobody got them to work
reliably.
I wouldn't blame just the md file, though - part of the problem is just
that there is less slack for bad allocation on a x86 due to the small
register set, and many instructions have additional constraints (QIregs,
shift counts have to be in cl, %eax and %edx are special for muldiv etc).
Even when the output code is correct, you can certainly see "interesting"
artifacts of reload.c, where it moves things around for no good reason etc
(spilling a register only to immediately reload it, for example). And that
seems to happen much more on x86 than it does on machines with larger
register sets.
> I agree with Jeff that, sure the problem is solvable, but to fix it is
> certainly non-trivial. A new reload pass is going to break many
> things faster than it fixes things for a long time to come...
Agreed.
But as a user of gcc I'd certainly prefer bugs that can be explained by
active development rather than bugs that can be explained by people not
daring to touch the hairiest file in all of gcc.
Linus