On Thu, Jan 08, 2015 at 03:00:02PM -0700, Jeff Law wrote:
> On 01/06/15 04:21, James Greenhalgh wrote:
> >-A @code{define_insn} is an RTL expression containing four or five
> >operands:
> >+A @code{define_insn} contains either four or five components:
> How about
> A @code{define_insn} contains the following components:
>
> >
> > @enumerate
> > @item
> >-An optional name. The presence of a name indicate that this instruction
> >-pattern can perform a certain standard job for the RTL-generation
> >-pass of the compiler. This pass knows certain names and will use
> >-the instruction patterns with those names, if the names are defined
> >-in the machine description.
> >-
> >-The absence of a name is indicated by writing an empty string
> >-where the name should go. Nameless instruction patterns are never
> >-used for generating RTL code, but they may permit several simpler insns
> >-to be combined later on.
> >-
> >-Names that are not thus known and used in RTL-generation have no
> >-effect; they are equivalent to no name at all.
> >+The @dfn{insn name}: When expanding from gimple to RTL, and when
> >performing
> >+optimizations, the compiler looks for patterns with certain names,
> IIRC reload looks for specific named patterns as well. There may be
> other places that look for standard named patterns.
>
> Which makes me wonder how hard we should try to nail this down. Maybe
> something along the lines of passes which generate new insns may look
> for standard names.
This whole business with standard names isn't specific to define_insn
(also define_insn_and_split and define_expand), so perhaps it should
be moved elsewhere?
Patterns with names that start with a '*' behave like nameless patterns
as well (except where the name is printed, like in dump files). This
should be mentioned in the same place too I think (it currently is
mentioned _somewhere_ I think, but I cannot find it, hrm).
Segher
