This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A new patch for floating point conditional mov on PPo


> 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  |                         |
-------------------------------------------------------------------------



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]