PATCH: Re: ICE in 920624-1.c with -O3 -funroll-loops on vax-dec-ultrix4.3
law@redhat.com
law@redhat.com
Tue Feb 5 07:40:00 GMT 2002
In message <20020205124050.GR17128@atrey.karlin.mff.cuni.cz>, Jan Hubicka write
s:
> > On Mon, Feb 04, 2002 at 08:29:58PM -0700, law@redhat.com wrote:
> > > What we could do in the short term is to delete the jump table when we
> > > optimize the jump, but leave the CODE_LABEL alone. That deals with the
> > > immediate problem of needing to get unused jump tables out of the insn
> > > stream. By leaving the CODE_LABEL in the stream we avoid dangling
> > > references in normal insns which used that label for computations.
> >
> > If we're going to dream, I think using CODE_LABEL at all for this
> > is incorrect. Except for a couple of oddballs it isn't a label to
> > code at all -- it's a label to .rodata. And for those Harvard ports
> > that have different representations for code and data pointers,
> > having both use a LABEL_REF causes problems.
> >
> > So we should have a TABLEJUMP_REF that references the jump table,
> > and if for some reason the jump table gets optimized away without
> > optimizing out the references, we can emit a zero instead.
>
> Perhaps using symbol_ref is just fine. For calls we also do use
> symbol refs to addresses inside code segment.
No. I really prefer Richard's idea of creating a new _REF node. Why?
Because LABEL_REF implies a label in the code segment and SYMBOL_REF
implies a label outside the code segment. For the label before a jump
table, we don't know where it'll end up. Some ports put the table in
the code segment, others in readonly data, others in r/w data.
jeff
More information about the Gcc-bugs
mailing list