public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Michael Meissner <meissner@linux.ibm.com>,
	gcc-patches@gcc.gnu.org,        dje.gcc@gmail.com
Subject: Re: [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h
Date: Mon, 22 Jul 2019 05:56:00 -0000	[thread overview]
Message-ID: <20190722054213.GV20882@gate.crashing.org> (raw)
In-Reply-To: <20190720161308.GA6730@ibm-toto.the-meissners.org>

Hi!

On Sat, Jul 20, 2019 at 12:13:08PM -0400, Michael Meissner wrote:
> 2019-07-20  Michael Meissner  <meissner@linux.ibm.com>
> 
> 	* config/rs6000/rs6000-internal.h (rs6000_hard_regno_mode_ok_p):
> 	Move various declarations relating to addressing and register
> 	allocation to rs6000-internal.h from rs6000.c so that in the
> 	future we can move things out of rs6000.c.

Just say
  (rs6000_hard_regno_mode_ok_p): New declaration.
for the things that only had a definition before.

> 	Make the static arrays global,

That's not this entry.  Say that in the entries where it applies.

> 	and define them in rs6000.c.

Say that in the corresponding entry for rs6000.c .

> 	(enum rs6000_reg_type): Likewise.

This one always was a declaration.

(... ten gazillion "Likewise." ...)
Most of those are *not* the same thing.  Don't say "likewise" if not
the same comment applies.

If it is hard to write a proper changelog, your patch series probably
could use some restructuring.  Or sometimes the changelog you need just
is more work than you would prefer.

You don't necessarily have to keep the same order in the changelog as
in the patch, if that helps.  But roughly the same order helps review,
so please consider that too ;-)

> +/* Simplfy register classes into simpler classifications.  We assume

(Typo, not new, but still a typo :-) )

> +/* Register classes we care about in secondary reload or go if legitimate
> +   address.  We only need to worry about GPR, FPR, and Altivec registers here,
> +   along an ANY field that is the OR of the 3 register classes.  */

We haven't had GO_IF_LEGITIMATE_ADDRESS for ten years now, please don't
introduce new references to it ;-)

> +#define RELOAD_REG_VALID	0x0001	/* Mode valid in register..  */
> +#define RELOAD_REG_MULTIPLE	0x0002	/* Mode takes multiple registers.  */
> +#define RELOAD_REG_INDEXED	0x0004	/* Reg+reg addressing.  */
> +#define RELOAD_REG_OFFSET	0x0008	/* Reg+offset addressing. */
> +#define RELOAD_REG_PRE_INCDEC	0x0010	/* PRE_INC/PRE_DEC valid.  */
> +#define RELOAD_REG_PRE_MODIFY	0x0020	/* PRE_MODIFY valid.  */
> +#define RELOAD_REG_AND_M16	0x0040	/* AND -16 addressing.  */
> +#define RELOAD_REG_QUAD_OFFSET	0x0080	/* quad offset is limited.  */

Why all the extra zeroes?  If you introduce some 0x100 later, just leave
the 0x80 as 0x80 please, that is much more readable.


It's hard to tell whether the problem is factored sanely, or if this
creates a big mountain of spaghetti instead.  Can you show how this is
used later?

Normally, you send a whole series, and then perhaps many of the first
are preparatory only, but a reviewer can see where things are headed,
and *then* simple refactorings like this can make sense.  The way this
patch looks now you are just making a lot of data global.


Segher

  parent reply	other threads:[~2019-07-22  5:42 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-28  0:06 Add support for PowerPC prefixed memory instructions and pc-relative support (Intro) Michael Meissner
2019-06-28  0:12 ` [PATCH] PowerPC Prefixed Memory, Patch #3, Update predicates Michael Meissner
2019-06-28 13:20   ` Segher Boessenkool
2019-06-28 14:56     ` Bill Schmidt
2019-06-28 18:54     ` Michael Meissner
2019-06-28 18:50 ` [PATCH] PowerPC Prefixed Memory, Patch #4, Add pc-relative reference support Michael Meissner
2019-07-03 22:20   ` Segher Boessenkool
2019-07-08 18:53     ` Michael Meissner
2019-07-08 18:54       ` Segher Boessenkool
2019-07-09 17:36         ` [PATCH, committed] PowerPC Prefixed Memory, Patch #5 (move create_TOC_reference) Michael Meissner
2019-07-09 18:34           ` Segher Boessenkool
2019-07-09 22:42 ` [PATCH], PowerPC, Patch #6, Create pc-relative addressing insns Michael Meissner
2019-07-10 17:43   ` Segher Boessenkool
2019-07-10 17:57     ` Michael Meissner
2019-07-10 18:55       ` Segher Boessenkool
2019-07-10 21:51   ` [PATCH], PowerPC, Patch #6, revision 2, " Michael Meissner
2019-07-11 20:10     ` Segher Boessenkool
2019-07-11 21:04       ` Michael Meissner
2019-07-11 21:38         ` Segher Boessenkool
2019-07-10  0:28 ` [PATCH], PowerPC, Patch #7, Split up SIGNED_34BIT and SIGNED_16BIT macros Michael Meissner
2019-07-10 18:37   ` Segher Boessenkool
2019-07-11 12:17 ` [PATCH], PowerPC, Patch #8, rename rs6000_prefixed_address Michael Meissner
2019-07-11 21:37   ` Segher Boessenkool
2019-07-11 19:45 ` [PATCH], PowerPC, Patch #9, Refine calculation of whether an address offset is d-form, ds-form, or dq-form Michael Meissner
2019-07-12 17:05   ` Segher Boessenkool
2019-07-16 18:00     ` Michael Meissner
2019-07-16 23:31       ` Segher Boessenkool
2019-07-16  6:35 ` [PATCH], Patch #6, revision 3, Create pc-relative addressing insns Michael Meissner
2019-07-16 21:09   ` Segher Boessenkool
2019-07-18 19:34     ` Michael Meissner
2019-07-18 19:43       ` Segher Boessenkool
2019-07-17  5:44   ` [PATCH], Patch #6, revision 3, (Test on AIX and Darwin) Michael Meissner
2019-07-20 16:28 ` [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h Michael Meissner
2019-07-20 16:54   ` David Edelsohn
2019-07-22 18:37     ` Michael Meissner
2019-07-22 19:55       ` Segher Boessenkool
2019-07-21 18:13   ` Segher Boessenkool
2019-07-22 18:59     ` Michael Meissner
2019-07-22 20:45       ` Segher Boessenkool
2019-07-22  5:56   ` Segher Boessenkool [this message]
2019-07-22 19:33     ` Michael Meissner
2019-07-22 21:33       ` Segher Boessenkool
2019-07-22 23:11         ` Michael Meissner
2019-07-25 13:30           ` Segher Boessenkool

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=20190722054213.GV20882@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=meissner@linux.ibm.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).