Re: patch for handling NOTE_INSN_DELETED_LABELS in scheduling

[Bernd Schmidt <bernds at redhat dot com>]

On Tue, 24 Jul 2001 amacleod@cygnus.com wrote:

> >> > the if_convert optimization will sometimes deleted user labels.
> >> > if they occur at the beginning of an if or then block, and these
> >> > blocks could otherwise be merged, flow will change the
> >> > labels to a NOTE_INSN_DELETED_LABEL. If we then run the
> >> > extended basic block scheduler, these note all get moved to the
> >> > top of the function, and the get emitted in the wrong place.
> >>
> >> What kind of failure does this cause?
>
> Because its not a NOTE_INSN that is in the list of notes to save
> at their current location, they get removed by remove_note.
> These are labels whose address has been taken, which is why flow
> turned them into notes in the first place. The end result is that
> without the note, no label ever gets generated, and we end up with a
> reference to a non existant label. IA64 hides this fact by
> deciding that if there is a reference to a deleted label,
> we'll just create it at the top of the function, which causes a
> runtime failure instead of a compile time one because there address
> are not correct. Im not sure why that code is there.
> the testcase 990208-1.c demonstrates the problem. You'll see the
> 2 labels generated at the same address a the top of the function.

Does this happen only at -O3?  In that case, I'd argue that this is
actually valid behaviour from the compiler.  Since we never jump to
the label, we are relatively free to reorder move it around in the
function (otherwise we wouldn't have deleted it in the first place).
The test is trying to verify that doit has been inlined, and expects
to find two different copies of the label (one in f, one in g).
With -O3, we inline both f and g.

All a NOTE_INSN_DELETED_LABEL really means is that we must emit a
label, somewhere, so that we don't get undefined references.  Where
we place the label shouldn't really matter.


Bernd