From patchwork Tue Jan 6 11:21:39 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: James Greenhalgh X-Patchwork-Id: 425625 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 060F51400A0 for ; Tue, 6 Jan 2015 22:22:40 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type; q=dns; s=default; b=Wn6jV+QBE3D1EBsL FiqdUepLtSkz7byZ4zAl847w/rDJKl3bilq2OthQOgTdND40CxoUfRd2ntUoNwEo +eRPxjTJpEXtxjZzX1cY1JXAM3Wuh8sLAlmNSbnikaXWUPALP/JjRGCvTOfaslaK DEiKNQ94QTTGutURS/g9/WSwuKY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type; s=default; bh=1si02c0sswzQbq4sY9N2sU JfzTo=; b=etKA8DUBjLWo40wiuZuCPFR21ZjC8CTNXTGmGQPU6d0247/uwpVZUW ou+o4AFRQ2EgeOklAKo30Y95JFPbJAsS8Ry4EQVeW7PCAx62He1C/6gU2WxFZu1P SawVzOPughQyimBKt0B4yq5uV4lKXJWT5IIQA7w4aNqjgtQAb4g2o= Received: (qmail 32559 invoked by alias); 6 Jan 2015 11:22:30 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 32496 invoked by uid 89); 6 Jan 2015 11:22:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL, BAYES_00, MEDICAL_SUBJECT, SPF_PASS autolearn=no version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Jan 2015 11:22:27 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by service87.mimecast.com; Tue, 06 Jan 2015 11:22:25 +0000 Received: from e106375-lin.cambridge.arm.com ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2015 11:22:23 +0000 From: James Greenhalgh To: gcc-patches@gcc.gnu.org Cc: gerald@pfeifer.com, joseph@codesourcery.com Subject: [Patch docs 2/5] Update "Instruction Patterns" in md.texi Date: Tue, 6 Jan 2015 11:21:39 +0000 Message-Id: <1420543302-11008-3-git-send-email-james.greenhalgh@arm.com> In-Reply-To: <1420543302-11008-1-git-send-email-james.greenhalgh@arm.com> References: <1420543302-11008-1-git-send-email-james.greenhalgh@arm.com> MIME-Version: 1.0 X-MC-Unique: 115010611222505301 X-IsSubscribed: yes Hi, This patch updates the second section of md.texi - "Everything about Patterns". 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 * doc/md.texi (Instruction Patterns): Update text. (Example): Update text. diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi index 0277f14..b852981 100644 --- a/gcc/doc/md.texi +++ b/gcc/doc/md.texi @@ -115,85 +115,98 @@ emit the final assembly code. For this purpose, names are ignored. All @cindex instruction patterns @findex define_insn -Each instruction pattern contains an incomplete RTL expression, with pieces -to be filled in later, operand constraints that restrict how the pieces can -be filled in, and an output pattern or C code to generate the assembler -output, all wrapped up in a @code{define_insn} expression. +A @code{define_insn} expression is used to define instruction patterns +to which insns may be matched. A @code{define_insn} expression contains +an incomplete RTL expression, with pieces to be filled in later, operand +constraints that restrict how the pieces can be filled in, and an output +template or C code to generate the assembler output. -A @code{define_insn} is an RTL expression containing four or five operands: +A @code{define_insn} contains either four or five 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, +collectively known as the standard pattern names (@pxref{Standard Names}). +The target-independent infrastructure in the compiler which references +these names is generally accessed through the interfaces defined +in @code{optabs.c}. + +Names that are not listed as one of the standard pattern names are not +used directly by the target-independent code. However, machine +descriptions may themselves make use of named patterns in +@code{define_expand} or @code{define_split} expressions. + +It is also possible to define a nameless instruction pattern. This uses +an empty string in place of the name. Nameless instruction patterns cannot +be used when generating RTL code, but they may be matched against during +the combine and split passes of the compiler. + +Where names are given to instruction patterns, these must be unique +in the machine description file. For the purpose of debugging the compiler, you may also specify a name beginning with the @samp{*} character. Such a name is used only -for identifying the instruction in RTL dumps; it is entirely equivalent -to having a nameless pattern for all other purposes. +for identifying the instruction in RTL dumps; it is equivalent to having +a nameless pattern for all other purposes. Names beginning with the +@samp{*} character are not required to be unique. @item -The @dfn{RTL template} (@pxref{RTL Template}) is a vector of incomplete -RTL expressions which show what the instruction should look like. It is -incomplete because it may contain @code{match_operand}, +The @dfn{RTL template}: This is a vector of incomplete RTL expressions +which describe the semantics of the instruction (@pxref{RTL Template}). +It is incomplete because it may contain @code{match_operand}, @code{match_operator}, and @code{match_dup} expressions that stand for operands of the instruction. -If the vector has only one element, that element is the template for the -instruction pattern. If the vector has multiple elements, then the -instruction pattern is a @code{parallel} expression containing the -elements described. +If the vector has multiple elements, the RTL template is treated as a +@code{parallel} expression. @item @cindex pattern conditions @cindex conditions, in patterns -A condition. This is a string which contains a C expression that is -the final test to decide whether an insn body matches this pattern. +The condition: This is a string which contains a C expression. When the +compiler attempts to match RTL against a pattern, the condition is +evaluated. If the condition evaluates to @code{true}, the match is +permitted. The condition may be an empty string, which is treated +as always @code{true}. @cindex named patterns and conditions -For a named pattern, the condition (if present) may not depend on -the data in the insn being matched, but only the target-machine-type -flags. The compiler needs to test these conditions during -initialization in order to learn exactly which named instructions are -available in a particular run. +For a named pattern, the condition may not depend on the data in the +insn being matched, but only the target-machine-type flags. The compiler +needs to test these conditions during initialization in order to learn +exactly which named instructions are available in a particular run. @findex operands For nameless patterns, the condition is applied only when matching an individual insn, and only after the insn has matched the pattern's recognition template. The insn's operands may be found in the vector -@code{operands}. For an insn where the condition has once matched, it -can't be used to control register allocation, for example by excluding -certain hard registers or hard register combinations. +@code{operands}. + +For an insn where the condition has once matched, it +cannot later be used to control register allocation by excluding +certain register or value combinations. @item -The @dfn{output template}: a string that says how to output matching -insns as assembler code. @samp{%} in this string specifies where -to substitute the value of an operand. @xref{Output Template}. +The @dfn{output template} or @dfn{output statement}: This is either +a string, or a fragment of C code which returns a string. -When simple substitution isn't general enough, you can specify a piece -of C code to compute the output. @xref{Output Statement}. +If it is a string, that string forms the output template and defines how +a matched insn should be output as assembler code +(@pxref{Output Template}). If it is a fragment of C code, this should +return a string which will be used as the output template +(@pxref{Output Statement}). @item -Optionally, a vector containing the values of attributes for insns matching -this pattern. @xref{Insn Attributes}. +The @dfn{insn attributes}: This is an optional vector containing the values of +attributes for insns matching this pattern (@pxref{Insn Attributes}). @end enumerate @node Example @section Example of @code{define_insn} @cindex @code{define_insn} example -Here is an actual example of an instruction pattern, for the 68000/68020. +Here is an example of an instruction pattern, taken from the machine +description for the 68000/68020. @smallexample (define_insn "tstsi" @@ -223,12 +236,12 @@ This can also be written using braced strings: @}) @end smallexample -This is an instruction that sets the condition codes based on the value of -a general operand. It has no condition, so any insn whose RTL description -has the form shown may be handled according to this pattern. The name -@samp{tstsi} means ``test a @code{SImode} value'' and tells the RTL generation -pass that, when it is necessary to test such a value, an insn to do so -can be constructed using this pattern. +This describes an instruction which sets the condition codes based on the +value of a general operand. It has no condition, so any insn with an RTL +description of the form shown may be matched to this pattern. The name +@samp{tstsi} means ``test a @code{SImode} value'' and tells the RTL +generation pass that, when it is necessary to test such a value, an insn +to do so can be constructed using this pattern. The output control string is a piece of C code which chooses which output template to return based on the kind of operand and the specific