* Problem: delete_dead_jumptables and constant pool references
@ 2001-08-13 14:40 Ulrich Weigand
2001-08-13 15:44 ` Richard Henderson
0 siblings, 1 reply; 5+ messages in thread
From: Ulrich Weigand @ 2001-08-13 14:40 UTC (permalink / raw)
To: gcc; +Cc: uweigand, hpenner
Hello,
I'm experiencing problems with the s390 port on mainline that
appear to be caused by frontend code.
The symptom is that dead jumptables are sometimes not deleted,
which causes references to labels that have already been deleted
to stay in the code, causing subsequent link failures.
Now, I'm not very familiar with the flow.c code, but it appears
that the routine delete_dead_jumptables () should have deleted
those tables. However, it doesn't on s390, because jump tables
are referenced from the constant pool and hence never have a
LABEL_NUSES of zero. (Even after the insn loading the label
from the pool was deleted, the pool entry itself is never removed
until shortly before outputting the pool.)
However, in the routine propagate_block_delete_insn (), there
is similar code dealing with dead jumptables. There, an explicit
check is made whether the table is referenced only from the
constant pool.
I've simply added an equivalent check to delete_dead_jumptables (),
and now my test case compiles correctly. (See patch below.)
Is this the correct approach to fix the problem?
Bye,
Ulrich
Index: gcc/flow.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/flow.c,v
retrieving revision 1.462
diff -c -p -r1.462 flow.c
*** flow.c 2001/08/10 16:19:07 1.462
--- flow.c 2001/08/13 21:28:05
*************** delete_dead_jumptables ()
*** 4675,4681 ****
{
next = NEXT_INSN (insn);
if (GET_CODE (insn) == CODE_LABEL
! && LABEL_NUSES (insn) == 0
&& GET_CODE (next) == JUMP_INSN
&& (GET_CODE (PATTERN (next)) == ADDR_VEC
|| GET_CODE (PATTERN (next)) == ADDR_DIFF_VEC))
--- 4675,4681 ----
{
next = NEXT_INSN (insn);
if (GET_CODE (insn) == CODE_LABEL
! && LABEL_NUSES (insn) == LABEL_PRESERVE_P (insn)
&& GET_CODE (next) == JUMP_INSN
&& (GET_CODE (PATTERN (next)) == ADDR_VEC
|| GET_CODE (PATTERN (next)) == ADDR_DIFF_VEC))
*************** delete_dead_jumptables ()
*** 4683,4689 ****
if (rtl_dump_file)
fprintf (rtl_dump_file, "Dead jumptable %i removed\n", INSN_UID (insn));
flow_delete_insn (NEXT_INSN (insn));
! flow_delete_insn (insn);
next = NEXT_INSN (next);
}
}
--- 4683,4695 ----
if (rtl_dump_file)
fprintf (rtl_dump_file, "Dead jumptable %i removed\n", INSN_UID (insn));
flow_delete_insn (NEXT_INSN (insn));
!
! /* The label may be forced if it has been put in the constant
! pool. If that is the only use we must discard the table
! jump following it, but not the label itself. */
! if (!LABEL_PRESERVE_P (insn))
! flow_delete_insn (insn);
!
next = NEXT_INSN (next);
}
}
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem: delete_dead_jumptables and constant pool references
2001-08-13 14:40 Problem: delete_dead_jumptables and constant pool references Ulrich Weigand
@ 2001-08-13 15:44 ` Richard Henderson
2001-09-20 15:14 ` Ulrich Weigand
0 siblings, 1 reply; 5+ messages in thread
From: Richard Henderson @ 2001-08-13 15:44 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gcc, uweigand, hpenner
On Mon, Aug 13, 2001 at 11:40:13PM +0200, Ulrich Weigand wrote:
> Is this the correct approach to fix the problem?
Not quite, the label should be deleted too, but by
turning it into a NOTE_INSN_DELETED_LABEL. Try
flow_delete_insn_chain (insn, NEXT_INSN (insn));
instead of the two flow_delete_insn calls.
r~
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem: delete_dead_jumptables and constant pool references
2001-08-13 15:44 ` Richard Henderson
@ 2001-09-20 15:14 ` Ulrich Weigand
2001-09-20 15:17 ` Richard Henderson
0 siblings, 1 reply; 5+ messages in thread
From: Ulrich Weigand @ 2001-09-20 15:14 UTC (permalink / raw)
To: Richard Henderson; +Cc: Ulrich Weigand, gcc, uweigand, hpenner, gcc-patches
Richard Henderson wrote:
> On Mon, Aug 13, 2001 at 11:40:13PM +0200, Ulrich Weigand wrote:
> > Is this the correct approach to fix the problem?
>
> Not quite, the label should be deleted too, but by
> turning it into a NOTE_INSN_DELETED_LABEL. Try
>
> flow_delete_insn_chain (insn, NEXT_INSN (insn));
>
> instead of the two flow_delete_insn calls.
Sorry for the late reply; I finally got around to try this out.
The patch below, implementing your suggestion, does indeed fix
the problem I'm experiencing as well.
OK to apply?
ChangeLog:
* flow.c (delete_dead_jumptables): Delete jumptable if
the only reference is from the literal pool.
Index: gcc/flow.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/flow.c,v
retrieving revision 1.478
diff -c -p -r1.478 flow.c
*** flow.c 2001/09/16 20:21:24 1.478
--- flow.c 2001/09/20 21:33:24
*************** delete_dead_jumptables ()
*** 795,809 ****
{
next = NEXT_INSN (insn);
if (GET_CODE (insn) == CODE_LABEL
! && LABEL_NUSES (insn) == 0
&& GET_CODE (next) == JUMP_INSN
&& (GET_CODE (PATTERN (next)) == ADDR_VEC
|| GET_CODE (PATTERN (next)) == ADDR_DIFF_VEC))
{
if (rtl_dump_file)
fprintf (rtl_dump_file, "Dead jumptable %i removed\n", INSN_UID (insn));
! flow_delete_insn (NEXT_INSN (insn));
! flow_delete_insn (insn);
next = NEXT_INSN (next);
}
}
--- 795,808 ----
{
next = NEXT_INSN (insn);
if (GET_CODE (insn) == CODE_LABEL
! && LABEL_NUSES (insn) == LABEL_PRESERVE_P (insn)
&& GET_CODE (next) == JUMP_INSN
&& (GET_CODE (PATTERN (next)) == ADDR_VEC
|| GET_CODE (PATTERN (next)) == ADDR_DIFF_VEC))
{
if (rtl_dump_file)
fprintf (rtl_dump_file, "Dead jumptable %i removed\n", INSN_UID (insn));
! flow_delete_insn_chain (insn, NEXT_INSN (insn));
next = NEXT_INSN (next);
}
}
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem: delete_dead_jumptables and constant pool references
2001-09-20 15:14 ` Ulrich Weigand
@ 2001-09-20 15:17 ` Richard Henderson
2001-09-20 15:36 ` Ulrich Weigand
0 siblings, 1 reply; 5+ messages in thread
From: Richard Henderson @ 2001-09-20 15:17 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gcc, uweigand, hpenner, gcc-patches
On Fri, Sep 21, 2001 at 12:14:44AM +0200, Ulrich Weigand wrote:
> Sorry for the late reply; I finally got around to try this out.
> The patch below, implementing your suggestion, does indeed fix
> the problem I'm experiencing as well.
It's so late that it will be incorrect by tomorrow. Jan has
a patch to change the behaviour of flow_delete_insn.
r~
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem: delete_dead_jumptables and constant pool references
2001-09-20 15:17 ` Richard Henderson
@ 2001-09-20 15:36 ` Ulrich Weigand
0 siblings, 0 replies; 5+ messages in thread
From: Ulrich Weigand @ 2001-09-20 15:36 UTC (permalink / raw)
To: Richard Henderson; +Cc: Ulrich Weigand, gcc, uweigand, hpenner, gcc-patches
Richard Henderson wrote:
> On Fri, Sep 21, 2001 at 12:14:44AM +0200, Ulrich Weigand wrote:
> > Sorry for the late reply; I finally got around to try this out.
> > The patch below, implementing your suggestion, does indeed fix
> > the problem I'm experiencing as well.
>
> It's so late that it will be incorrect by tomorrow. Jan has
> a patch to change the behaviour of flow_delete_insn.
Oops, I didn't realize this patch was related. Thanks for pointing
this out; I'll redo the patch once Jan's is in ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-09-20 15:36 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-13 14:40 Problem: delete_dead_jumptables and constant pool references Ulrich Weigand
2001-08-13 15:44 ` Richard Henderson
2001-09-20 15:14 ` Ulrich Weigand
2001-09-20 15:17 ` Richard Henderson
2001-09-20 15:36 ` Ulrich Weigand
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).