Re: cfgrtl

[law at redhat dot com]

 In message <20020205122030.GL17128@atrey.karlin.mff.cuni.cz>, Jan Hubicka 
write
s:
 > In long term we probably want to get around this completely - make 
jumptables
 > kind of CONST_POOL datastructure and avoid them from insn stream. In fact
 > I did that for cfg-branch (didn't comited yet). THere I simply remove
 > the jumptables from insn stream keeping them referenced only by the labels
 > and re-insert them after the live jumptables before final.
I don't think completely removing this information from the insn stream is
wise.  In an ideal world we should be able to reconstruct everything we need
to compile a function from the RTL data structures.  We're a long long way from
that right now, but that doesn't mean we should make the situation worse.

The jump table (in whatever structural form we want to use) should be
attached to the tablejump/casesi insn.

 > I am not 100% sure it is good idea to merge the insn computing address with
 > the jumptable insn, as they are physically separate insns and we must schedu
 > le
 > them accordingly, so at least in lowlevel RTL we should have them separate.
I don't think it's a good idea and I've never suggested we do this.


 > > The point behind the combination is to clearly define for the optimizers
 > 
 > What exactly you mean by the combination?
The point behind defining the behavior more clearly is we can add it to
the documentation and to the various checkers in the compiler.

Right now we have *WAY* too many conventions which are defined solely by
the implementation of the compiler and are neither documented nor verified
for consistency.  Worse yet, the conventions are only understood by a limited
number of people.

If we agree on the two actions for what happens when we convert a tablejump,
then we can document them and have the compiler perform internal consistency
checks to verify that optimizers are not violating those rules for
transforming tablejumps.

 > I believe all optimizers do use the way b) relativly consistently, but I may
 > be mistaken.
You are unfortunately mistaken.  There are several locations which do not
follow those conventions, both in new code and in old code.

jeff