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.


The code before the call to constrain_operands looks like:

        insn_code_number = recog_memoized (insn);
        insn_extract (insn);
        for (i = 0; i < insn_n_operands[insn_code_number]; i++)
          {
            if (GET_CODE (recog_operand[i]) == SUBREG)
              recog_operand[i] = alter_subreg (recog_operand[i]);
            else if (GET_CODE (recog_operand[i]) == PLUS
                     || GET_CODE (recog_operand[i]) == MULT)
              recog_operand[i] = walk_alter_subreg (recog_operand[i]);
          }

        for (i = 0; i < insn_n_dups[insn_code_number]; i++)
          {
            if (GET_CODE (*recog_dup_loc[i]) == SUBREG)
              *recog_dup_loc[i] = alter_subreg (*recog_dup_loc[i]);
            else if (GET_CODE (*recog_dup_loc[i]) == PLUS
                     || GET_CODE (*recog_dup_loc[i]) == MULT)
              *recog_dup_loc[i] = walk_alter_subreg (*recog_dup_loc[i]);
          }


Note that recog_memoized will not actually recognize the insn again
if INSN_CODE (insn) has a non-negative value.  For reasons I never
really agreed with, reload will stomp modify instructions, but not
reset INSN_CODE to force the insn to be re-recognized except for a
few special cases.

Now, I believe the cases where this braindamage can have an undesirable
effect stem from register elimination.  I do not believe that
register elimination is likely to lead to such a problem with the 
compare instructions.

However, given the complexities of reload the the uncertainty of it's
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.

jeff


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