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]
Other format: [Raw text]

Re: [Patch, cilk, C++] Fix cilk testsuite failure


On Wed, 2014-01-15 at 22:47 -0700, Jeff Law wrote:
> On 01/15/14 21:23, Andrew Pinski wrote:

> >> Tested on mips-mti-linux-gnu with no regressions.
> >>
> >> OK to checkin?
> >
> > No, this really should be fixed in the target side.  In fact for MIPS
> > there is an instruction which does a conditional move based on the FP
> > CC register (movt/movf).  So you need to look into why the wrong
> > pattern is being selected instead.

> Or maybe during expansion.
> 
> jeff

Well, I thought it was worth a shot.  Looking at the instruction causing
the problem we have the RTX:

            (insn:TI 76 79 98 (set (reg:SI 2 $2 [orig:228 D.1939+-3 ] [228])
                    (if_then_else:SI (ne:SI (reg:CC 67 $fcc0)
                            (const_int 0 [0]))
                        (reg:SI 2 $2 [orig:228 D.1939+-3 ] [228])
                        (reg:SI 4 $4 [246]))) 609 {*movsi_on_cc}
                 (nil))

And it is being handled by the define_insn:

;; MIPS4 Conditional move instructions.

(define_insn "*mov<GPR:mode>_on_<MOVECC:mode>"
  [(set (match_operand:GPR 0 "register_operand" "=d,d")
        (if_then_else:GPR
         (match_operator 4 "equality_operator"
                [(match_operand:MOVECC 1 "register_operand" "<MOVECC:reg>,<MOVECC:reg>")
                 (const_int 0)])
         (match_operand:GPR 2 "reg_or_0_operand" "dJ,0")
         (match_operand:GPR 3 "reg_or_0_operand" "0,dJ")))]
  "ISA_HAS_CONDMOVE"
  "@
    mov%T4\t%0,%z2,%1
    mov%t4\t%0,%z3,%1"
  [(set_attr "type" "condmove")
   (set_attr "mode" "<GPR:MODE>")])

%T4 is using the mode of operand 4 to determine if it should generate
movz or movf.  If that mode is CC it uses movf/movt and otherwise it uses
movz/movn.  I tried tweaking the conditional move define_insn to use
%T1 and %t1 instead of %T4 and %t4 but that caused regressions because the
%T code is also looking at the node to see if it is a NE or a EQ.

Given that we have a CC reg type is it reasonable/correct that the ne
comparision is SI mode and not CC mode?

Steve Ellcey
sellcey@mips.com



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