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: cfgrtl


law@redhat.com writes:

> True, all we're leaving in the insn stream is raw computations, which should
> not reference labels -- the tablejump should be the only instruction which
> references the label before the jump table.

Unfortunately, this is not true.  Jump address computations often
reference the address of the jump table, typically because they want
to add it to the value loaded from the jump table.  Look at the rs6000
tablejumpsi expander, for instance.

> You absolutely can't leave the jump table in the stream if you remove its
> associated tablejump insn.  This is doubly true if you've removed the
> labels referenced by the jump table (as happens with the current sources
> if you don't have my change).

Why not?  I've seen this happen many times.  In fact, there's special
code in final to deal with the case of a jump table referencing labels
that don't exist (they get replaced with NULL).  Of course, this is
hideously ugly, but it does work.

> In an ideal world we would attach the jump table to the tablejump
> itself which would cause the jump table to automatically go away if
> we delete the tablejump insn.

In an ideal world, the jump table would be a data structure, like a
CONST_DOUBLE, not code.  I would very much encourage moving to this
arrangement.  This would have the additional advantage that, once
computed goto is implemented in a new port, jump tables would Just
Work.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>


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