Re: PATCH: Re: ICE in 920624-1.c with -O3 -funroll-loops on

[law at redhat dot com]

 In message <20020205124632.GS17128@atrey.karlin.mff.cuni.cz>, Jan Hubicka 
write
s:
 > Because the label before jumptable is special by the fact that it is not
 > in code segment for most cases.  By removing the following jumptable you
 > convert special code_label to not special code_label and create invalid
 > CFG. Sick, I know.
No, it doesn't create an invalid CFG if it does, then the CFG was broken to
begin with.

Let's look at the cases.

First, let's assume we don't optimize the tablejump at all.  By convention the
magic label as well as the jump table are defined as being outside any defined
basic blocks.  ie, they exist between basic blocks, much like barriers.

Now let's assume we have an optimizable tablejump and we remove the jump
table, twiddle the tablejump, but leave the magic code label alone.

  The vast majority of the time twiddling the tablejump will either directly
  or indirectly (via dead code elimination) cause all the references to the
  magic code label to be removed.  Once the last reference has been removed,
  the code label itself gets removed.  Clearly if it's not in the stream,
  then it's not going to cause a problem.

  However, there is a period of time where the label is in the stream, but
  this should not cause significant problems.  If you look at the insns we
  will be left with after transforming the tablejump and removing the
  jump table we'll have something like this:

    simplejump

    barrier

    magic code label

    [ Optional barrier, which I believe we want to eliminate if it's still
      in the stream. ]

    normal code label for whatever real code followed the jump table



  We effectively have consecutive labels, which can and should be
  combined.  Even if they are not combined, what we have is a label which
  is not the target of a branch, but which is referenced by computation
  insns.  Such labels have well defined semantics, both in terms of how
  the CFG is constructed (they have no effect) and in terms of how they
  can move around in the insn stream.


 > You must remove it and convert to NOTE_DELETED_LABEL as code labels other
 > than tablejump are prohibited outside basic block.  In case we keep the
 > instructions to compute address in the stream by the accident, we result
 > in accesing code segment for no putpose.
I don't think this is necessary.  Though if it would make you feel better,
we can convert the label into a NOTE_DELETED_LABEL.

99.9% of the time the computation insns are going to be deleted by dead
code elimination.  That 0.1% of the time all they'll do is compute an 
address that will never be used, just like if we take the address of a
label using GCC's address-of-a-label extension.

 > This is not correct - it is easy to construct testcases where the jumptable
 > has been left in the stream with the old jump optimizer.
 > THey has been removed just in "majority of cases".
Sorry, based on my knowledge of how jump.c works I don't believe you.  I'd
like to see an example of when the old jump optimizer would leave an 
jump table in the stream.

jeff