This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: A new patch for floating point conditional mov on PPo
- To: law at cygnus dot com
- Subject: Re: A new patch for floating point conditional mov on PPo
- From: john at feith dot com (John Wehle)
- Date: Wed, 10 Jun 1998 20:33:45 -0400
- cc: hjl at lucon dot org, egcs-patches at cygnus dot com
> In message <199806102153.RAA17221@jwlab.FEITH.COM>you write:
> > I believe that this is already handled by:
> >
> > #ifdef REGISTER_CONSTRAINTS
> > if (! constrain_operands (insn_code_number, 1))
> > fatal_insn_not_found (insn);
> > #endif
> >
> > in final.c (final_scan_insn).
> This checks that the constraints match, not that the predicate
> matches or that the pattern's condition is true.
I believe that what I'm referring to doesn't involve the predicate
or the pattern's condition.
The pattern in question look like:
(define_insn "cmpsi_1"
[(set (cc0)
(compare (match_operand:SI 0 "nonimmediate_operand" "mr,r")
(match_operand:SI 1 "general_operand" "ri,mr")))]
"GET_CODE (operands[0]) != MEM || GET_CODE (operands[1]) != MEM"
"*
{
if (CONSTANT_P (operands[0]) || GET_CODE (operands[1]) == MEM)
{
cc_status.flags |= CC_REVERSED;
return AS2 (cmp%L0,%0,%1);
}
return AS2 (cmp%L0,%1,%0);
}")
Now if we are in agreement that constrain_operands ensures that
the constraints match (i.e. "mr,r"), then how can CONSTANT_P in
this pattern ever be useful? And GET_CODE (operands[1]) == MEM
in this same bit of code also doesn't seem very useful since Intel
allows operands[1] to be a MEM.
> exact operation, if we're going to change that code, I would
> recommend that we call abort for the "can't happen case" rather than
> assuming it can't happen and silently generating incorrect code if
> it does happen.
Agreed, however I fail to see why more than the call to constrain_operands
is needed in order to not worry about removing CONSTANT_P (operands[0])
given the constraints associated with the pattern in question.
Are you saying that there may be situations in which constrain_operands
will not enforce the constraints of "mr,r"?
-- John
-------------------------------------------------------------------------
| Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com |
| John Wehle | Fax: 1-215-540-5495 | |
-------------------------------------------------------------------------