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: john at feith dot com (John Wehle)
- Subject: Re: A new patch for floating point conditional mov on PPo
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 11 Jun 1998 00:27:58 -0600
- cc: hjl at lucon dot org, egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199806110033.UAA17849@jwlab.FEITH.COM>you write:
> 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.
Thanks. Sorry, I kind of locked in on the "nonimmediate" operand as
the thing which was supposed to prevent those cases from happening.
[ ... ]
> 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.
Yea. I think you're right.
> Are you saying that there may be situations in which constrain_operands
> will not enforce the constraints of "mr,r"?
Not that I'm aware of.
So, what patch do I need to go find in my mailbox to clean this up :-)
jeff