From patchwork Sat Apr 6 22:04:58 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Bosscher X-Patchwork-Id: 234454 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 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 8EB132C008D for ; Sun, 7 Apr 2013 08:05:52 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:from:date:message-id:subject:to:cc:content-type; q=dns; s=default; b=N8koGkwfYODUHTwKniRTKv2XVf9yZn0Jeg2QTWyp3sA yXOEzSphWl1Vgl4DUk52bZS0yjz9lhqT8uho6GfLODtnyM2ccea8yshIXkZifmeu I8IKu7lMWg3cQFFXG7E6yiTB0QN/WVlFMyB1iB8RJiWMN2oUVO8oNjhMrLJxsdPI = 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 :mime-version:from:date:message-id:subject:to:cc:content-type; s=default; bh=FsOauY80YyzInNh1HD2R8lj1cfY=; b=N5u+lMWrX22tm9NEo 1lWCy2SPaHcsznNmrwDfCDsCLJ5FYY+PBG4RDKpbtaz5QbhrsvjaIW1coBppMF4C xNFtLgadksyvt0rPXEhNppZjEoM/8u/BqnGHDWHAgHKJJyoRDonHaWnqeYBO1CMm LBOGoZzETY3WQYeo7YDgDh1o7o= Received: (qmail 32713 invoked by alias); 6 Apr 2013 22:05:46 -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 32700 invoked by uid 89); 6 Apr 2013 22:05:45 -0000 X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, KHOP_RCVD_TRUST, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, RCVD_IN_NIX_SPAM, TW_CF autolearn=ham version=3.3.1 Received: from mail-vc0-f172.google.com (HELO mail-vc0-f172.google.com) (209.85.220.172) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sat, 06 Apr 2013 22:05:41 +0000 Received: by mail-vc0-f172.google.com with SMTP id gd11so900210vcb.31 for ; Sat, 06 Apr 2013 15:05:39 -0700 (PDT) X-Received: by 10.220.203.130 with SMTP id fi2mr11748332vcb.52.1365285939694; Sat, 06 Apr 2013 15:05:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.68.228 with HTTP; Sat, 6 Apr 2013 15:04:58 -0700 (PDT) From: Steven Bosscher Date: Sun, 7 Apr 2013 00:04:58 +0200 Message-ID: Subject: [patch] update documentation for SEQUENCE To: GCC Patches Cc: Gerald Pfeifer Hello, The existing documentation for SEQUENCE still states it is used for DEFINE_EXPAND sequences. I think I wasn't even hacking GCC when that practice was abandoned, and in the mean time some other uses of SEQUENCE have appeared in the compiler. So, a long-overdue documentation update. OK for trunk? Ciao! Steven * doc/rtl.texi (sequence): Rewrite documentation to match the current use of SEQUENCE rtl objects. * rtl.def (SEQUENCE): Likewise. Index: doc/rtl.texi =================================================================== --- doc/rtl.texi (revision 197532) +++ doc/rtl.texi (working copy) @@ -3099,18 +3099,11 @@ side-effects. @findex sequence @item (sequence [@var{insns} @dots{}]) -Represents a sequence of insns. Each of the @var{insns} that appears -in the vector is suitable for appearing in the chain of insns, so it -must be an @code{insn}, @code{jump_insn}, @code{call_insn}, -@code{code_label}, @code{barrier} or @code{note}. +Represents a sequence of insns. If a @code{sequence} appears in the +chain of insns, then each of the @var{insns} that appears in the sequence +must be suitable for appearing in the chain of insns, i.e. must satisfy +the @code{INSN_P} predicate. -A @code{sequence} RTX is never placed in an actual insn during RTL -generation. It represents the sequence of insns that result from a -@code{define_expand} @emph{before} those insns are passed to -@code{emit_insn} to insert them in the chain of insns. When actually -inserted, the individual sub-insns are separated out and the -@code{sequence} is forgotten. - After delay-slot scheduling is completed, an insn and all the insns that reside in its delay slots are grouped together into a @code{sequence}. The insn requiring the delay slot is the first insn in the vector; @@ -3123,6 +3116,19 @@ the effect of the insns in the delay slots. In su the branch and should be executed only if the branch is taken; otherwise the insn should be executed only if the branch is not taken. @xref{Delay Slots}. + +Some back ends also use @code{sequence} objects for purposes other than +delay-slot groups. This is not supported in the common parts of the +compiler, which treat such sequences as delay-slot groups. + +DWARF2 Call Frame Address (CFA) adjustments are sometimes also expressed +using @code{sequence} objects as the value of a @code{RTX_FRAME_RELATED_P} +note. This only happens if the CFA adjustments cannot be easily derived +from the pattern of the instruction to which the note is attached. In +such cases, the value of the note is used instead of best-guesing the +semantics of the instruction. The back end can attach notes containing +a @code{sequence} of @code{set} patterns that express the effect of the +parent instruction. @end table These expression codes appear in place of a side effect, as the body of Index: rtl.def =================================================================== --- rtl.def (revision 197533) +++ rtl.def (working copy) @@ -102,10 +102,24 @@ DEF_RTL_EXPR(EXPR_LIST, "expr_list", "ee", RTX_EXT The insns are represented in print by their uids. */ DEF_RTL_EXPR(INSN_LIST, "insn_list", "ue", RTX_EXTRA) -/* SEQUENCE appears in the result of a `gen_...' function - for a DEFINE_EXPAND that wants to make several insns. - Its elements are the bodies of the insns that should be made. - `emit_insn' takes the SEQUENCE apart and makes separate insns. */ +/* SEQUENCE is used in late passes of the compiler to group insns for + one reason or another. + + For example, after delay slot filling, branch instructions with filled + delay slots are represented as a SEQUENCE of length 1 + n_delay_slots, + with the branch instruction in XEXPVEC(seq, 0, 0) and the instructions + occupying the delay slots in the remaining XEXPVEC slots. + + Another place where a SEQUENCE may appear, is in REG_FRAME_RELATED_EXPR + notes, to express complex operations that are not obvious from the insn + to which the REG_FRAME_RELATED_EXPR note is attached. In this usage of + SEQUENCE, the sequence vector slots do not hold real instructions but + only pseudo-instructions that can be translated to DWARF CFA expressions. + + Some back ends also use SEQUENCE to group insns in bundles. + + Much of the compiler infrastructure is not prepared to handle SEQUENCE + objects. Only passes after pass_free_cfg are expected to handle them. */ DEF_RTL_EXPR(SEQUENCE, "sequence", "E", RTX_EXTRA) /* Represents a non-global base address. This is only used in alias.c. */