From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25783 invoked by alias); 5 Feb 2002 15:51:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 25663 invoked from network); 5 Feb 2002 15:50:58 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 5 Feb 2002 15:50:58 -0000 Received: from porcupine.cygnus.com (cse.sfbay.redhat.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id HAA23640; Tue, 5 Feb 2002 07:50:53 -0800 (PST) Received: from porcupine.cygnus.com (law@localhost) by porcupine.cygnus.com (8.11.6/8.11.6) with ESMTP id g15FmLJ27035; Tue, 5 Feb 2002 08:48:21 -0700 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Jan Hubicka cc: John David Anglin , rth@redhat.com, gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: PATCH: Re: ICE in 920624-1.c with -O3 -funroll-loops on Reply-To: law@redhat.com From: law@redhat.com In-reply-to: Your message of Tue, 05 Feb 2002 13:46:32 +0100. <20020205124632.GS17128@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Feb 2002 08:50:00 -0000 Message-ID: <27034.1012924100@porcupine.cygnus.com> X-SW-Source: 2002-02/txt/msg00386.txt.bz2 In message <20020205124632.GS17128@atrey.karlin.mff.cuni.cz>, Jan Hubicka write s: > Because the label before jumptable is special by the fact that it is not > in code segment for most cases. By removing the following jumptable you > convert special code_label to not special code_label and create invalid > CFG. Sick, I know. No, it doesn't create an invalid CFG if it does, then the CFG was broken to begin with. Let's look at the cases. First, let's assume we don't optimize the tablejump at all. By convention the magic label as well as the jump table are defined as being outside any defined basic blocks. ie, they exist between basic blocks, much like barriers. Now let's assume we have an optimizable tablejump and we remove the jump table, twiddle the tablejump, but leave the magic code label alone. The vast majority of the time twiddling the tablejump will either directly or indirectly (via dead code elimination) cause all the references to the magic code label to be removed. Once the last reference has been removed, the code label itself gets removed. Clearly if it's not in the stream, then it's not going to cause a problem. However, there is a period of time where the label is in the stream, but this should not cause significant problems. If you look at the insns we will be left with after transforming the tablejump and removing the jump table we'll have something like this: simplejump barrier magic code label [ Optional barrier, which I believe we want to eliminate if it's still in the stream. ] normal code label for whatever real code followed the jump table We effectively have consecutive labels, which can and should be combined. Even if they are not combined, what we have is a label which 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. 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 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. jeff