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

[Revital1 Eres <ERES at il dot ibm dot com>]

trevor_smigiel@playstation.sony.com wrote on 10/09/2007 22:06:02:

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

OK - I'll send a patch to fix it then.

Revital

>
> 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;
> > > > + }")
> > > > +
> > >
> > >
> >
>