Re: BCT optimization

[Joern Rennecke <amylaar at cygnus dot co dot uk>]

> 	Michael and I have been discussing how to generalize the BCT
> optimization for all of our needs.
> 
> 	Currently the BCT initialization code is quite PowerPC-specific: a
> GPR and a COUNT_REGISTER_REGNUM register are generated.  The iteration
> count is loaded into the GPR and then transferred into the count register
> performing a manual reload because constants cannot be loaded into the
> PowerPC CTR directly.  This sequence clearly should be a separate pattern
> to allow the machine description to load the counter in a
> machine-dependent way.

FWIW, the SH has a decrement-and-test instruction, so the pattern would
expand into these two instructions:

(define_insn "dect"
  [(set (reg:SI 18)
        (eq:SI (match_operand:SI 0 "arith_reg_operand" "+r") (const_int 1)))
   (set (match_dup 0) (plus:SI (match_dup 0) (const_int -1)))]
  "TARGET_SH2"
  "dt   %0"
  [(set_attr "type" "arith")])

(define_insn "branch_false"
  [(set (pc) (if_then_else (eq (reg:SI 18) (const_int 0))
                           (label_ref (match_operand 0 "" ""))
                           (pc)))]
  ""
  "* return output_branch (0, insn, operands);"
  [(set_attr "type" "cbranch")])

Note that "+r" mean that the counter register is a general register.
So before reload, a vanilla SImode pseudo will do.

> 	In some cases, the register allocated needs to be communicated
> between the initialization pattern and the decrement_and_branch pattern.
> I can see three ways to accoplish this and I am not sure which is best:
> 
> 	1) Pass an empty RTX into the initialization pattern.  Have the
> preparation statements in the pattern call gen_rtx_REG, filling in the
> RTX.  The loop instrumentation code would then have the filled-in RTX to
> pass as one of the parameters to the decrement_and_branch insn.

Could you elaborate what you mean with an 'empty RTX' ?