From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2791 invoked by alias); 4 Aug 2007 08:18:54 -0000 Received: (qmail 2782 invoked by uid 22791); 4 Aug 2007 08:18:53 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 04 Aug 2007 08:18:48 +0000 Received: (qmail 30754 invoked from network); 4 Aug 2007 08:18:46 -0000 Received: from unknown (HELO gateway) (10.0.0.100) by mail.codesourcery.com with SMTP; 4 Aug 2007 08:18:46 -0000 Received: by gateway (Postfix, from userid 1010) id 0AF2C6C136; Sat, 4 Aug 2007 01:18:45 -0700 (PDT) From: Richard Sandiford To: Sandra Loosemore Mail-Followup-To: Sandra Loosemore ,GCC Patches , David Ung , Nigel Stephens , Ian Lance Taylor , richard@codesourcery.com Cc: GCC Patches , David Ung , Nigel Stephens , Ian Lance Taylor Subject: Re: revised PATCH: per-function back end reinitialization, part 1/2 References: <46AE3DA9.8080601@codesourcery.com> Date: Sat, 04 Aug 2007 08:18:00 -0000 In-Reply-To: <46AE3DA9.8080601@codesourcery.com> (Sandra Loosemore's message of "Mon\, 30 Jul 2007 15\:36\:09 -0400") Message-ID: <87tzrfbtlm.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-08/txt/msg00229.txt.bz2 Sandra Loosemore writes: > When last we left this patch, the general consensus seemed to be that > it needed to be cleaned up to enforce better separation of the > one-time versus target-specific initialization parts during regular > startup, and to use the same function for target initialization during > startup as during subsequent calls for re-initialization to avoid > bit-rot. See, for instance, previous discussion here: > > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00763.html > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00850.html > > I've now done that rewrite. This is the non-MIPS-specific part of the > patch -- the MIPS-specific part, to implement selecting > mips16/nomips16 on a per-function basis, is almost unchanged from the > previous version, and I'll repost that in a separate message. Besides > the MIPS testing (both with and without -mflip-mips16), I also tried > to bootstrap on i686, but that's been dying for me with some unrelated > error while building libjava. I did, however, verify that there are > no regressions in the gcc testsuite on i686. Thanks. FWIW, having complained before, this looks really good to me. It certainly addresses my concerns. Just a couple of very minor niggles: > + /* Default the algn_* variables to 1 if they're still unset, and > + set up the align_*_log variables. */ > + static void > + init_alignments (void) > + { > + if (align_loops <= 0) align_loops = 1; > + if (align_loops_max_skip > align_loops || !align_loops) > + align_loops_max_skip = align_loops - 1; > + align_loops_log = floor_log2 (align_loops * 2 - 1); > + if (align_jumps <= 0) align_jumps = 1; > + if (align_jumps_max_skip > align_jumps || !align_jumps) > + align_jumps_max_skip = align_jumps - 1; > + align_jumps_log = floor_log2 (align_jumps * 2 - 1); > + if (align_labels <= 0) align_labels = 1; > + align_labels_log = floor_log2 (align_labels * 2 - 1); > + if (align_labels_max_skip > align_labels || !align_labels) > + align_labels_max_skip = align_labels - 1; > + if (align_functions <= 0) align_functions = 1; > + align_functions_log = floor_log2 (align_functions * 2 - 1); Not your fault, but seeing as you're moving this code, could you reformat it to follow coding conventions? No "if (...) foo;" lines. > ! /* This function can be called multiple times to reinitialize the compiler > ! back end when register classes or instruction sets have changed, > ! before each function. */ > ! static void > ! backend_init_target (void) > ! { > ! Stray line. A couple of other instances too. > + /* Assign register numbers to the globally defined register rtx. > + This must be done at runtime because the register number field > + is in a union and some compilers can't initialize unions. */ I think the second sentence is redundant now; we have to initialize it at run time because the values may depend on the mode, and because the function may be called by target_reinit. Richard