public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard@codesourcery.com>
To: Sandra Loosemore <sandra@codesourcery.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	 David Ung <davidu@mips.com>,  Nigel Stephens <nigel@mips.com>,
	 Ian Lance Taylor <iant@google.com>
Subject: Re: revised PATCH: per-function back end reinitialization, part 1/2
Date: Sat, 04 Aug 2007 08:18:00 -0000	[thread overview]
Message-ID: <87tzrfbtlm.fsf@firetop.home> (raw)
In-Reply-To: <46AE3DA9.8080601@codesourcery.com> (Sandra Loosemore's message 	of "Mon\, 30 Jul 2007 15\:36\:09 -0400")

Sandra Loosemore <sandra@codesourcery.com> 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

      reply	other threads:[~2007-08-04  8:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-30 19:36 Sandra Loosemore
2007-08-04  8:18 ` Richard Sandiford [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tzrfbtlm.fsf@firetop.home \
    --to=richard@codesourcery.com \
    --cc=davidu@mips.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iant@google.com \
    --cc=nigel@mips.com \
    --cc=sandra@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).