Re: RTL creation

[Zack Weinberg <zack at codesourcery dot com>]

On Sun, Jan 20, 2002 at 10:04:48PM -0800, Danish Samad wrote:
> hello,
> 
> After reading the machine description manual I deduce
> that named insruction patterns(in the .md file)  are
> used to create unoptimized RTL instructions. Further
> the manual also states that the RTL generation pass
> only looks for names that are hard coded in the
> compiler, other names will be ignored. 

Yah.  For each named pattern, you can have either a named _insn_,
which translates directly to an RTL insn, or a named _expander_, which
allows you to convert a named pattern into a sequence of
machine-specific insns.  With expanders, you also need anonymous insns
in the .md file to match the result of each expander.

Some patterns are optional, others are not.  The section "Standard
Names" of the manual lists most of the named patterns that are
meaningful to machine independent code; the documentation of which
patterns _must_ be present is sketchier.

> After examinig the source code I did not find any named patterns in
> any file, except an enum in insn-output.c containing named patterns.
> So how does gcc generate RTL instructions from the tree?  and
> exactly how are the named patterns in the md file used to generate
> RTL?

For each named pattern, these things happen:

- insn-flags.h #defines HAVE_pattern to the C test expression for that
pattern. 

- insn-emit.c contains a gen_pattern function which will generate RTL
for that pattern when called.

- insn-codes.h lists a CODE_FOR_pattern entry in its enumeration.

- insn-opinit.c may contain logic which stores CODE_FOR_pattern into
one of the optab entries.

- insn-output.c contains a huge table mapping CODE_FOR_pattern to the
  gen_pattern function (among other things).

The tree->RTL converter does two different things with all this
information.  For some named patterns, it looks up an entry in an
optab, discovers that there is a CODE_FOR_pattern number there, and
calls the related gen_pattern function through the mapping table.  For
others, it has a block of code conditional on HAVE_pattern, which
calls gen_pattern directly.

Named patterns can also be referenced from machine-dependent logic
(the MACHINE.c file, or C fragments in the md file) by using the
gen_NAME functions directly.  For instance:

(define_insn "x86_fnstcw_1"
  [(set (match_operand:HI 0 "memory_operand" "=m")
        (unspec:HI [(reg:HI 18)] 11))]
  "TARGET_80387"
  "fnstcw\t%0"
  [(set_attr "length" "2")
   (set_attr "mode" "HI")
   (set_attr "i387" "1")
   (set_attr "ppro_uops" "few")])

This pattern is not going to show up in any optab or machine-
independent source file, but the x86 back end is free to call
gen_x86_fnstcw_1 itself: in i386.c you will find

/* Output code to initialize control word copies used by trunc?f?i
   patterns.  NORMAL is set to current control word, while ROUND_DOWN
   is set to control word rounding downwards.  */
void
emit_i387_cw_initialization (normal, round_down)
     rtx normal, round_down;
{
  rtx reg = gen_reg_rtx (HImode);

  emit_insn (gen_x86_fnstcw_1 (normal));
  emit_move_insn (reg, normal);
  if (!TARGET_PARTIAL_REG_STALL && !optimize_size
      && !TARGET_64BIT)
    emit_insn (gen_movsi_insv_1 (reg, GEN_INT (0xc)));
  else
    emit_insn (gen_iorhi3 (reg, reg, GEN_INT (0xc00)));
  emit_move_insn (round_down, reg);
}

The documentation in this area is rather sketchy.  We'd appreciate
patches which make it more detailed.

zw