This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Re: ICE in 920624-1.c with -O3 -funroll-loops on vax-dec-ultrix4.3


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]