This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Detecting casesi insns
- To: richard dot earnshaw at arm dot com
- Subject: Re: Detecting casesi insns
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 21 Oct 1999 13:36:52 -0600
- cc: gcc-patches at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <199910210946.KAA03860@cam-mail1.cambridge.arm.com>you write:
>
> Another thing that sprung to mind was that JUMP_LABEL is dangerous as it
> stands if a target has any insns that can contain more than one code
> label. In these circumstances there are many occasions where you have to
> rescan the whole insn to ensure that you have fixed all the labels within
> it (this is precisely the problem with the casesi insn, which contains two
> labels, the label preceeding the ADDR_VEC and the label for the default
> branch).
>
> I wonder if it would make sense for JUMP_LABEL to be made into a vector?
> It could then contain a list of all the labels mentioned in an insn. For
> some optimizations it might make sense only to try with the first element
> of the vector, but when fixing other things up it would save having to
> rescan the insn; in particular, it would be a good reminder to programmers
> that there isn't guaranteed to be exactly one label to fix.
Not sure on this one.
A lot of the stuff we do with JUMP_LABEL could go away if we dis-connected the
insn chain for most of the opt passes and worked primarily on the lists of
insns within basic blocks and edges between blocks (cse, local-alloc, etc) or
strictly on the edges between blocks (jump).
We'd need some way to re-wire things so that we can emit assembly code, which
would imply that each out edge in the BB structure would have a condition
associated with it. With that kind of model we don't really even need/want
jump insns to appear in the insn chain until possibly just before final
output.
But that's further off and something we'll want to experiment with before
deciding it's a "good thing".
jeff