This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Kill gen_sequence


   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.
   
I checked very carefully for this, but it is possible I
missed something.

To be honest the cases in which this happens are cases where
the generic compiler should have optimized things away.  Examples:

1) Setjmp to current instruction.

2) Conditional move where both sources are identical to
   the destination.

3) Normal move where src == dest.

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

   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);

is possible.  In fact, emit_insn{,s}_after DOES this optimization
already!  What do we get from your suggestion?

I don't see any advantage to your proposed "enhancement"
to SEQUENCE rtl.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]