This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: I387 commutative fpop patterns
> On Fri, Nov 19, 1999 at 01:43:17AM +0100, Jan Hubicka wrote:
> > There is some code to handle the "two address" instructions (ie those that
> > contains "0" in constraint.
>
> And regmove doesn't notice the existing "0,fm"/"fm,0" pairs?
> Believable -- that's kinda ugly to check for.
Don't seems to. I am geting consistently better code.
I was checking for the purposes and except the regmove also regclass and reload
seems to contain code to handle '%' in superrior way to symetric constraints...
(this was one of the changes that was sleeping in my old backend hacks I did
last year. Now with this patch and those Pentium scheduling patches I sent last week I get
consistently better results in all XaoS benchmarks now so I can throw away all
that scrap).
>
> > There is problem with reg-stack. It does substitue registers and prevents
> > patterns from matching.
>
> I'm very puzzled by this statement. The existing patterns _do_
> use a matching constraint, the only thing they lack is the %.
> So what changed that we couldn't match?
Reg-stack puts the result to "top of stack" and one of operand there too.
When that operands happends to be the second, the constraints don't match, because
insn is swapped.
>
> > + case PLUS:
> > + case MULT:
> > + return GET_MODE_CLASS (GET_MODE (op)) == MODE_FLOAT;
>
> No need to check explicitly for PLUS/MULT; check GET_RTX_CLASS == 'c'.
Can I be sure that it will never match thinks like OR or AND or some other
commutative operands that we don't support for ?Fmodes?
Honza
>
>
> r~