PATCH: Re: ICE in 920624-1.c with -O3 -funroll-loops on

Jan Hubicka jh@suse.cz
Tue Feb 5 10:27:00 GMT 2002


>   We effectively have consecutive labels, which can and should be
>   combined.  Even if they are not combined, what we have is a label which

This is the problem. We do have CODE_LABEL outside basic block.
Our definition of CFG is that CODE_LABELs (except for magical ones)
appears in the head of basic block. There can not be multiple labels
in single basic block and there can not be labels outside basic blocks.

Combining labels is handled by creating empty basic block and elliminating
them subsequently.

We are targetting to situation where there is nothing outside basic block,
as sane ILs should have. That means eliminating of jumptables and majority
of INSN_NOTES so we are relativly far from that goal. I am working on
the INSN_NOTES slowly anyway.

>   is not the target of a branch, but which is referenced by computation
>   insns.  Such labels have well defined semantics, both in terms of how
>   the CFG is constructed (they have no effect) and in terms of how they
>   can move around in the insn stream.
> 
> 
>  > You must remove it and convert to NOTE_DELETED_LABEL as code labels other
>  > than tablejump are prohibited outside basic block.  In case we keep the
>  > instructions to compute address in the stream by the accident, we result
>  > in accesing code segment for no putpose.
> I don't think this is necessary.  Though if it would make you feel better,
> we can convert the label into a NOTE_DELETED_LABEL.

Yes, otherwise verify_flow_info will abort, at least.
You got that right in your patch by using delete_insn_chain that cares
converison to DELETED_LABEL thats why it worked for you.
> 
> 99.9% of the time the computation insns are going to be deleted by dead
> code elimination.  That 0.1% of the time all they'll do is compute an 
> address that will never be used, just like if we take the address of a

It will be used - we will read from it and throw away the value.
The actual read from code segment may be problem, so we need to ensure that
we eliminate the insns in 100%. ALso some ports allow different MEM expresisons
to code segment and to data segment and they actually do test CODE_LABEL
to magickness so we may result in invalid insn.

I believe that this is easy to do - just lets prohibit simplification of
jumptables after reload so flow will always do the action.

> label using GCC's address-of-a-label extension.
> 
>  > This is not correct - it is easy to construct testcases where the jumptable
>  > has been left in the stream with the old jump optimizer.
>  > THey has been removed just in "majority of cases".
> Sorry, based on my knowledge of how jump.c works I don't believe you.  I'd
> like to see an example of when the old jump optimizer would leave an 
> jump table in the stream.

One of testcases has been invariant jumptable in the loop. THe compuation
has been then moved outside loop and jump lost track when killing
the dead code.

Honza
> 
> jeff
> 



More information about the Gcc-bugs mailing list