Re: [PATCH] Modulo-scheduling improvements. Patch 2 of 2. (re-submission)

[trevor_smigiel at playstation dot sony dot com]

Revital,

The part that describes "condition logic" only applies to the specific
condition field of a defined_expand, not to the if statement in the
code.  When the if statement is false, the pattern is expanded like a
define_insn and all of the (use ()) statements are emitted.  The code
that calls gen_doloop_end then calls doloop_condition_get, which fails
causing the expansion to fail.  I wonder if there are situations where
it would not fail, in which case the code would be wrong.

The FAIL is necessary.  Or move the condition of the if statement
into the second field of the define_expand.

Trevor


* Revital1 Eres <ERES@il.ibm.com> [2007-09-10 06:55]:
> > Sorry I didn't notice this before, but shouldn't there be a FAIL at the
> > end of the doloop_end pattern?
> 
> Looking at the gcc internals: (Chapter 14: Machine Descriptions)
> 
> "... If a define_expand is used, one of three things happens, based on the
> condition logic. The condition logic may manually create new insns for
> the insn list, say via emit_insn(), and invoke DONE.  For certain named
> patterns, it may invoke FAIL to tell the compiler to use an alternate
> way of performing that task. If it invokes neither DONE nor FAIL, the
> template given in the pattern is inserted, as if the define_expand were
> a define_insn."
> 
> IIUC we should not add this FAIL as we are not interested in retrying
> to apply this pattern if (optimize > 0 && flag_modulo_sched) is false.
> 
> thanks,
> Revital
> 
> > Trevor
> >
> > > + ;; Define the subtract-one-and-jump insns so loop.c
> > > + ;; knows what to generate.
> > > + (define_expand "doloop_end"
> > > +   [(use (match_operand 0 "" ""))      ; loop pseudo
> > > +    (use (match_operand 1 "" ""))      ; iterations; zero if unknown
> > > +    (use (match_operand 2 "" ""))      ; max iterations
> > > +    (use (match_operand 3 "" ""))      ; loop level
> > > +    (use (match_operand 4 "" ""))]     ; label
> > > +   ""
> > > +   "
> > > + {
> > > +   /* Currently SMS relies on the do-loop pattern to recognize loops
> > > +      where (1) the control part comprises of all insns defining
> and/or
> > > +      using a certain 'count' register and (2) the loop count can be
> > > +      adjusted by modifying this register prior to the loop.
> > > +.     ??? The possible introduction of a new block to initialize the
> > > +      new IV can potentially effects branch optimizations.  */
> > > +   if (optimize > 0 && flag_modulo_sched)
> > > +   {
> > > +     rtx s0;
> > > +     rtx bcomp;
> > > +     rtx loc_ref;
> > > +
> > > +     /* Only use this on innermost loops.  */
> > > +     if (INTVAL (operands[3]) > 1)
> > > +       FAIL;
> > > +     if (GET_MODE (operands[0]) != SImode)
> > > +       FAIL;
> > > +
> > > +     s0 = operands [0];
> > > +     emit_move_insn (s0, gen_rtx_PLUS (SImode, s0, GEN_INT (-1)));
> > > +     bcomp = gen_rtx_NE(SImode, s0, const0_rtx);
> > > +     loc_ref = gen_rtx_LABEL_REF (VOIDmode, operands [4]);
> > > +     emit_jump_insn (gen_rtx_SET (VOIDmode, pc_rtx,
> > > +                                  gen_rtx_IF_THEN_ELSE (VOIDmode,
> bcomp,
> > > +                                                        loc_ref,
> pc_rtx)));
> > > +
> > > +     DONE;
> > > +   }
> >       FAIL;
> > > + }")
> > > +
> >
> >
>