This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question about cfgrtl.c:flow_delete_block_noexpunge
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: law at redhat dot com, Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, gcc at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Date: Wed, 11 Jun 2003 10:07:28 +0100
- Subject: Re: Question about cfgrtl.c:flow_delete_block_noexpunge
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> On Tue, Jun 10, 2003 at 08:41:32PM -0600, law@redhat.com wrote:
> > Kenner -- if you really want to fix this problem, attach the jump table
> > to the tablejump/switch insn itself. Doing that would enable cleanups
> > in several places within the compiler.
>
> Given my druthers, I wouldn't do that either. I'd have the
> jump tables in a data structure external to the insn stream.
>
> Consider that with the single exception of VAX and its funny
> casesi instruction, there is no architecture that absolutely
> requires the table to be adjacent to the jump insn (there are
> several that benefit from it, like arm, m68k, sh, but...).
> Keeping the table external means that we can solve problems
> related to basic block replication in trace scheduling and
> the like.
There are other problems with the case tables at present as well. I'd
really like to put compressed tables out-of-line for some ARM
compilations; but in order to do that I need the address of dispatch
instruction in addition to the address of the table. Currently GCC only
holds the latter and there's no way to get the former when emitting the
table.
R.