This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PPro patch #2
- To: hjl at lucon dot org (H.J. Lu)
- Subject: Re: PPro patch #2
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 08 Jun 1998 02:47:55 -0600
- cc: egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <m0yhyOy-000268C@ocean.lucon.org>you write:
> > The format of a conditional move is the same regardless of
> > the mode of the comparison operator:
> >
> > (set (dest) (if_then_else (comparison_operator
> > (comparison_arg1)
> > (comparison_arg2))
> > (result1)
> > (result2)))
> >
> >
> > So, when we call subst_stack_regs with such a pattern, we will always
> > to into the IF_THEN_ELSE case, regardless of what the comparison
> > operator is?!? What am I missing?
> >
> > How can we get into compare_for_stack_reg for a conditional move?
> > I don't see how that can happen anymore.
>
> subst_stack_regs_pat handles the register stack in the comparison
> insn, which is the one before the conditional move insn.
So, "comparison operator" is actually not the compare itself, but
the relational test (EQ, LE, NE, LT, etc etc)?
comparison_arg1 would be fpcc0 and comparison_arg2 would be
(const_int 0) right?
If that is the case, then your patch makes sense.
> Please check out subst_stack_regs_pat () and how it is called. It has
>
> switch (GET_CODE (SET_SRC (pat)))
> {
> case COMPARE:
> compare_for_stack_reg (insn, regstack, pat);
> break;
I was quite aware of this code, my questions stem from a misunderstanding
of how the cmove patterns worked. This is precisely why explaining
things in more detail is good. I'm not an x86 expert, so I do not
"just know" how the x86 works or how gcc's x86 target files work.
What seems obvious to you is not necessarily obvious to me.
Thanks,
jeff