This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Kill gen_sequence
- From: "David S. Miller" <davem at redhat dot com>
- To: joern dot rennecke at superh dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 06 Jun 2002 20:25:44 -0700 (PDT)
- Subject: Re: [RFC] Kill gen_sequence
- References: <3CFFBBAB.2AC695C0@superh.com>
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.