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.

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.


r~


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