This is the mail archive of the gcc-patches@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


> 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.
> 
> Or simply have a pass just before final that removes such refs.
> 
> > I think we'd want to largely treat the s390 like the other ports; with the
> > caveat that we dump the table into the constant pool relatively late in
> > the compilation process.    ie, I'd like to present the optimizers with
> > a common model for dealing with tablejumps.
> 
> It doesn't seem unreasonable to treat the entire table jump as a
> unit during early optimization.  You'd want to lower early enough 
> to move address computation out of loops when possible, but otherwise
> there's little that can actually be simplified wrt other code.

This IMO well fits the midlevel/lowlevel RTL design.  In my eyes the "final"
midRTL lowering should be followed by PRE to move invariants out of the loop,
so we will not lose optimization opurtunities and get the advnatage of
possibility to duplicate jumptables, that is important for superblock
formation. See for instance the interpreter in libjava, that do contain huge
switch for each instruction that is ifdefed out and replaced by indirect jumps
to avoid one jump instruction per simulation cycle. With tracer compiler will
be able to do the trick automagically.

Honza
> 
> 
> r~


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