On Sun, Apr 7, 2013 at 12:04 AM, Steven Bosscher <stevenb....@gmail.com> wrote:
> 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?
Ok.
Thanks,
Richard.
> 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. */
