This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 2.7.2.3 good, EGCS 1.0.3 bad for x86 subtract then test
- To: law at cygnus dot com
- Subject: Re: GCC 2.7.2.3 good, EGCS 1.0.3 bad for x86 subtract then test
- From: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>
- Date: Sat, 26 Dec 1998 23:10:18 +1300 (NZDT)
- Cc: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>, Richard Henderson <rth at cygnus dot com>, Jamie Lokier <egcs at tantalophile dot demon dot co dot uk>, Marc Lehmann <pcg at goof dot com>, egcs at cygnus dot com
- References: <"13956.18174.396993.213410"@ongaonga.elec.canterbury.ac.nz><16940.914651694@hurl.cygnus.com>
Jeffrey A Law writes:
>
> In message <13956.18174.396993.213410@ongaonga.elec.canterbury.ac.nz>you writ
> e:
> > Why not use the extra condition to prevent the combination if the
> > first input does not match the output operand?
> Because that can miss some valueable combination opportunities. It is also
> incorrect for a condition on a named pattern to reject any insn based on
> anything other than the target flags.
I realise you can't do this for named patterns but this is easily
overcome using named expanders (with exceptions for movMN and addP
patterns required by reload).
What valuable combination opportunities are missed if you write the
extra condition to only accept the valid operand combinations?
[I know this thread popped up a couple of months ago but I feel it was
not satisfactorily resolved...]
Michael.