[RFC] Kill gen_sequence

[David S. Miller]

   From: Joern Rennecke <joern.rennecke@superh.com>
   Date: Fri, 07 Jun 2002 14:42:50 +0100

   >    This allows us to just splice sequences into the insn stream as one
   >    unit, instead of having a loop that does pointer-chasing on the
   >    sequence and calls a function for each insn to splice it into the
   >    chain individually.
   > 
   > We can do that now, since:
   > 
   >         seq = get_insns ();
   >         end_sequence ();
   > 
   >         insert_at (seq, insn);
   
   Where is that insert_at defined?  And how does it know the last insn
   of the insn chain starting at insn, without traversing the chain?

There is this function in emit-rtl.c you can call, perhaps you've seen
it, it's called get_last_insn ().  You can use to get the end of the
chain without traversing it.

   > is possible.  In fact, emit_insn{,s}_after DOES this optimization
   > already!  What do we get from your suggestion?
   
   No, it doesn't.
   
emit_insns_after does so in current sources as does emit_insn_after in
my patches, see emit_insn_after_1 in that case.  It does this
optimization because it is easier to update the basic block
information in that way.

   > I don't see any advantage to your proposed "enhancement"
   > to SEQUENCE rtl.
   
   - Like your original proposal, it avoids garbage from one-insn sequences
     and sequence husks with different size than the next required sequence.

Only with your fixed size sequence cache, I don't like that
solution at all.  My proposal has zero hard-coded limitations.

   - In addition to that, it makes the last insn of the sequence readily
     available, thus allowing a splicing operation without the need to traverse
     an insn chain.

It is available, see get_last_insn ().

Now, are there any hard arguments against my sequence killing
changes?