[RFC] Kill gen_sequence

[Joern Rennecke]

"David S. Miller" wrote:
> 
>    From: Joern Rennecke <joern.rennecke@superh.com>
>    Date: Thu, 06 Jun 2002 20:44:43 +0100
> 
>    I remember that there were several of such splitters in sh.md.
>> Can you give my patch a run on SH to make sure some of the splitters
> can in fact generate no RTL so we can fix that?

I've just gone over the splitter and insn_and_splits in the sh.md files,
and indeed there are no zero-length splits at the moment.
gen_shifty_op and friends emit a nop in some instances, because final would
abort for an empty sequence.

There are some places in sh.md where it emits a no-op move.  This allows
the optimizers to attach a REG_EQUAL notes to them.  Such no-op moves
are deleted after reload, by the jump optimizer or the postreload pass.

So, no problem for splitters there - they can just emit a no-op move. 
	
>    I think we should keep SEQUENCEs, but change their structure.  Instead
>    of having a variable sized array of instructions, let's make them have
>    two pointers, one to the head of the sequence, and another to the tail.
> 
> Eh?  How does this deal with the problem I'm trying to solve?
> The problem is elimination of "throw away" RTL because it serves
> only to fragment the GC pools of the compiler.
> 
> SEQUENCEs can look how you want them to look, we still would end up
> throwing them away right after creating them.
> 
>    That makes sequences small and uniform in size, so keeping a small free
>    list avoids creating garbage (of course we don't want to peel one-insn
>    sequences then).
> 
> This doesn't work especially since the nesting of sequence stack can
> be arbitrarily deep, there are no limits and we do no want to impose
> any kind of limits.

Well, but in practice the sequence stack generally remains rather limited
in depth, so you are unlikely to see the free list growing very large.
If keeping a free list of sequences would be a problem, than keeping
free_sequence_stack would be even more of a problem.
Something else we could do would be to re-use the sequence_stack entries
to become sequences.  Or just don't make them SEQUENCE rtl, pass the
raw sequence_stack structure around.

That's probably the simplest solution.
 
>    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?
> 
> is possible.  In fact, emit_insn{,s}_after DOES this optimization
> already!  What do we get from your suggestion?

No, it doesn't.

  if (GET_CODE (pattern) == SEQUENCE)
    {
      int i;

      for (i = 0; i < XVECLEN (pattern, 0); i++)
        {
          insn = XVECEXP (pattern, 0, i);
          add_insn_after (insn, after);
          after = insn;
        }
    }

> 
> 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.
- 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.

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330