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: PPro patch #2



  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


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