On 01/06/15 04:21, James Greenhalgh wrote:
Hi,
This patch updates the RTL Template section of md.texi.
I was aiming to:
* Remove outdated details of the compiler.
* Remove long or obscure words that, while accurate, only served to
obfuscate a simple idea.
* Refer to similar things in a consistent fashion - in particular
trying to keep consistent use of "insn" and "pattern".
* Remove superflous examples, or waffling.
OK?
Thanks,
James
---
2015-01-06 James Greenhalgh<james.greenha...@arm.com>
* doc/md.texi (RTL Template): Update text.
0003-Patch-docs-3-5-Update-RTL-Template-in-md.texi.patch
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index b852981..a589f5b 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -257,25 +257,23 @@ type of CPU for which code is being generated.
@cindex recognizing insns
@cindex insns, recognizing
-The RTL template is used to define which insns match the particular pattern
+The RTL template is used to define which insns match the pattern
and how to find their operands. For named patterns, the RTL template also
-says how to construct an insn from specified operands.
+defines how to construct an insn from specified operands.
-Construction involves substituting specified operands into a copy of the
-template. Matching involves determining the values that serve as the
-operands in the insn being matched. Both of these activities are
-controlled by special expression types that direct matching and
-substitution of the operands.
+Constructing an insn involves substituting specified operands into a
+copy of the template. Matching an insn involves determining the values
+that serve as the operands in the insn being matched. Both of these
+activities are controlled by the special RTL expressions described below.
Matching also involves verifying that the values serving as operands
match their associated predicates. I guess that's discussed below and
probably doesn't need to be explicitly mentioned here.
@table @code
@findex match_operand
@item (match_operand:@var{m} @var{n} @var{predicate} @var{constraint})
This expression is a placeholder for operand number @var{n} of
-the insn. When constructing an insn, operand number @var{n}
-will be substituted at this point. When matching an insn, whatever
-appears at this position in the insn will be taken as operand
-number @var{n}; but it must satisfy @var{predicate} or this instruction
-pattern will not match at all.
+the instruction pattern. When constructing RTL, operand number @var{n}
+will be substituted at this point. When matching an insn, assuming the
+@var{predicate} is satisfied, whatever appears at this position in the
+insn will be taken as operand number @var{n}.
So are you referring to the operand predicates here or the insn's
condition? The new wording made me almost think you'd confused operand
predicates and insn conditions. This probably needs further refinement.
@@ -302,80 +300,89 @@ not always. For example, the predicate
@code{address_operand} uses
Many predicates accept @code{const_int} nodes even though their mode is
@code{VOIDmode}.
-@var{constraint} controls reloading and the choice of the best register
-class to use for a value, as explained later (@pxref{Constraints}).
-If the constraint would be an empty string, it can be omitted.
-
-People are often unclear on the difference between the constraint and the
-predicate. The predicate helps decide whether a given insn matches the
-pattern. The constraint plays no role in this decision; instead, it
-controls various decisions in the case of an insn which does match.
+@var{constraint} controls the best register class to use for a value,
+and therefore register allocation and reloading, as explained
+later (@pxref{Constraints}). If the constraint would be an empty
+string, it can be omitted.
+
+In summary, the predicate is used to control whether the instruction
+pattern is a valid match for an insn. The constraint is used to control
+register allocation decisions in the case of an instruction pattern which
+has already been matched to an insn.
+
+It is an error for the contraints of an operand to be impossible to fulfil
s/contraints/constraints/
+for operands which are valid for the predicate of the operand. Formally;
+for all operands for which the predicate would be true, there must exist
+at least one valid register class for that operand. Note that this
+restriction does not forbid accepting operands which will need additional
+handling to move them to a valid register class. This restriction would,
+however, prevent combining a constraint set requiring the use of an
+immediate value with a predicate allowing any operand, as it is not
+possible to convert all operand types to immediate values.
I wonder if it's worth mentioning that, having predicates which are
similar to the constraints in terms of what matches is generally preferred.
That's an overarching goal in how we want to write patterns these days.
It lessens the reliance on reload for producing proper code and
ultimately that tends to result in better performing code as well. This
can be added as a follow-up if you wish.
@@ -416,24 +424,29 @@ gen-function. The subexpressions of argument 3 are not
used;
only its expression code matters.
When @code{match_operator} is used in a pattern for matching an insn,
-it usually best if the operand number of the @code{match_operator}
-is higher than that of the actual operands of the insn. This improves
-register allocation because the register allocator often looks at
-operands 1 and 2 of insns to see if it can do register tying.
-
-There is no way to specify constraints in @code{match_operator}. The
-operand of the insn which corresponds to the @code{match_operator}
-never has any constraints because it is never reloaded as a whole.
-However, if parts of its @var{operands} are matched by
-@code{match_operand} patterns, those parts may have constraints of
-their own.
+it is usually best if the operand number of the @code{match_operator}
+is higher than that of the actual operands of the insn. This can
+improve register allocation because the register allocator often
+looks at operands 1 and 2 of insns to see if they are suitable
+for register tying.
Gak. I don't think the allocator cares anymore about the specific
operand numbering. I really wonder if we should just remove that stuff.
I think the only part that needs another iteration is the change where I
briefly thought you were referring to insn conditions rather than
operand predicates. THe rest is either OK as-is (where I didn't
comment) or after making the trivial changes.
