Re: [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h
Hi Mike, On Mon, Jul 22, 2019 at 06:37:35PM -0400, Michael Meissner wrote: > On Mon, Jul 22, 2019 at 03:56:26PM -0500, Segher Boessenkool wrote: > > That still needs an explanation: why is this a good thing, why do you > > want that change? Sometimes that is obvious of course, but here it is > > not. It would be a lot more obvious if there was more context. > > The trouble is to get that much context really relies on about several > additional patches to get to the functions in particular that should be split > out. In the normal workflow, you send a series of patches when it is ready. And if a series is not ready, you do not send it. You can also give context just in the emails, or send a work-in-progress patch just as FYI (please mark it clearly as such, then). But without context, how can I see if what a patch does is correct and useful? > As I implement stuff, I find myself neeting/wanting to access the stuff in > reg_addr in other files (predicates.md, and the new file rs6000-prefix.c). Then you first need to question if things are split up in a useful way the way things are, and then how it could be done better. > But it would be nice to have that information available to the other .c files > as well as the .md files. If many other modules need the data, then either: a) The module boundaries are not set nicely; or b) This is a central data structure, and should be treated as one. Segher
Re: [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h
On Mon, Jul 22, 2019 at 03:56:26PM -0500, Segher Boessenkool wrote: > That still needs an explanation: why is this a good thing, why do you > want that change? Sometimes that is obvious of course, but here it is > not. It would be a lot more obvious if there was more context. The trouble is to get that much context really relies on about several additional patches to get to the functions in particular that should be split out. As I implement stuff, I find myself neeting/wanting to access the stuff in reg_addr in other files (predicates.md, and the new file rs6000-prefix.c). In patch #9 in particular, I added yet another data stucture that was parallel to the information in reg_addr (originally called rs6000_offset_format, but based on your comments is now rs6000_insn_form for instruction format). Then I needed functions that given were a hard register and the move insn and it determined what instruction format (D/DS/DQ) was used so that we can decide whether the instruction is traditional or prefixed. I originally wrote with a lot of code to do that mapping, but once I added the DS_OFFSET mask and about 10 lines of code to setup DS_OFFSET, it became much simpler. But for now, I think I will just not worry about making rs6000.c smaller, and instead do the main work there rather than trying to split it out. I was hoping the split would be quick, and it doesn't seem to be. Splitting it out is somewhat of a side issue to me, and it looks like it is impeding getting the rest of the patches submitted. But it would be nice to have that information available to the other .c files as well as the .md files. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Re: [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h
On Mon, Jul 22, 2019 at 02:59:39PM -0400, Michael Meissner wrote: > On Mon, Jul 22, 2019 at 12:42:13AM -0500, Segher Boessenkool wrote: > > On Sat, Jul 20, 2019 at 12:13:08PM -0400, Michael Meissner wrote: > > > 2019-07-20 Michael Meissner > > > > > > * 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. > > This was a mechanical patch, just moving the swath of code from rs6000.c to > rs6000-internal.h. And yet, your changelog should be correct ;-) > So in change, I can go back to just: > > #define RELOAD_REG_VALID 0x01/* Mode valid in register.. */ > #define RELOAD_REG_MULTIPLE 0x02/* Mode takes multiple registers. */ > #define RELOAD_REG_INDEXED0x04/* Reg+reg addressing. */ > #define RELOAD_REG_OFFSET 0x08/* Reg+offset addressing. */ > #define RELOAD_REG_PRE_INCDEC 0x10/* PRE_INC/PRE_DEC valid. */ > #define RELOAD_REG_PRE_MODIFY 0x20/* PRE_MODIFY valid. */ > #define RELOAD_REG_AND_M160x40/* AND -16 addressing. */ > #define RELOAD_REG_QUAD_OFFSET0x80/* quad offset is limited. */ Yes. Just keep it as is. This is supposed to be a move, not a change. > Some time later if I continue with the current code, that would be changed to: Maybe. We'll see then. > I was just trying to save a step since I was moving the definitions any way to > add the alignment. A move should not introduce any unnecessary changes. This only is much more work for everyone (you: you need to write extra changelog for it. Me: I see there are extra changes, and now I have to check everything else, too). > > 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? > > The intention is to move bits to other files. In particular, I want to create > a new rs6000-prefixed.c file that contains the bits specific to prefixed > addressing. That isn't a good split. All addressing-related stuff in one file might make sense, just like the rs6000-call.c split did (which was worthwhile because all the huge builtin stuff naturally fit there as well). But only one kind of addressing? Nope, that does not sound good. > However, longer term, it would be nice to move other things from rs6000.c to > other files, such as the functions that deal with p8 fusion, and the > legitimate > address functions (which I still tend to mentally classify as GO_IF_LEGITIMATE > type functions, even as you mention, we no longer have GO_IF_LEGITIMATE*). But only where that makes sense. Dividing things is only good if a) the division has an obvious, fundamental meaning; b) the interface between that part and the rest is thin; c) there is something to actually *win* from dividing things. > > 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. > > This was intended to be just a mechanical patch to move things to the .h file. That still needs an explanation: why is this a good thing, why do you want that change? Sometimes that is obvious of course, but here it is not. It would be a lot more obvious if there was more context. Segher
Re: [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h
On Mon, Jul 22, 2019 at 02:36:00PM -0400, Michael Meissner wrote: > On Sun, Jul 21, 2019 at 12:41:51PM -0500, Segher Boessenkool wrote: > > On Sat, Jul 20, 2019 at 12:13:08PM -0400, Michael Meissner wrote: > > > I will be iterating on patch #9 and sending out a replacement shortly. > > > > > > This is patch #10. It moves the various data structures from rs6000.c to > > > > I'll review this tomorrow, fwiw. > > > > A general request: please don't send patches as replies to other emails. > > In the past you had asked me to group patches under a single overview patch. > I > can go back to sending patches individually. When you send a *series*, please send it as series; when you send individual patches, please send them individually. This is all about how people will get it in their email, and how they will handle it. This really *is* a series, just most patches do not exist yet, if I understand correctly. That is not ideal of course -- I cannot review it as a series, because I don't have the later patches. Sending the patches as replies to weeks-old other patches is less than useful. Segher
Re: [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h
On Mon, Jul 22, 2019 at 02:34:53PM -0400, Michael Meissner wrote: > On Sat, Jul 20, 2019 at 12:28:34PM -0400, David Edelsohn wrote: > > This patch needs to add rs6000-internal.h to tm_file in gcc/config.gcc > > for all of the powerpc/rs6000 targets. It also may need tm_p_file and > > tm_d_file definitions. > > While I agree it would make things easier if the declarations are available to > everybody, why wasn't this an issue when rs6000-internal.h was created to > allow > stuff to move out from rs6000.c to rs6000-logues.c? AIUI it is mostly needed to get dependencies right? Segher
Re: [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h
On Mon, Jul 22, 2019 at 12:42:13AM -0500, Segher Boessenkool wrote: > Hi! > > On Sat, Jul 20, 2019 at 12:13:08PM -0400, Michael Meissner wrote: > > 2019-07-20 Michael Meissner > > > > * 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. This was a mechanical patch, just moving the swath of code from rs6000.c to rs6000-internal.h. > (... 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 ;-) Well yes, while in general I would prefer to group things logically together for ChangeLog, I don't tend to do it because as you say it makes it easier for the review. > We haven't had GO_IF_LEGITIMATE_ADDRESS for ten years now, please don't > introduce new references to it ;-) Yep. > > +#define RELOAD_REG_VALID 0x0001 /* Mode valid in register.. */ > > +#define RELOAD_REG_MULTIPLE0x0002 /* 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. As I mentioned, I will be adding at least one new bit (RELOAD_REG_DS_OFFSET), but I have potential patches that add a few more (those are still in flux), and those would need the extra column. I personally DO NOT find mask definitions like: #define RELOAD_REG_VALID0x01/* Mode valid in register.. */ #define RELOAD_REG_MULTIPLE 0x02/* Mode takes multiple registers. */ #define RELOAD_REG_INDEXED 0x04/* Reg+reg addressing. */ #define RELOAD_REG_OFFSET 0x08/* Reg+offset addressing. */ #define RELOAD_REG_PRE_INCDEC 0x10/* PRE_INC/PRE_DEC valid. */ #define RELOAD_REG_PRE_MODIFY 0x20/* PRE_MODIFY valid. */ #define RELOAD_REG_AND_M16 0x40/* AND -16 addressing. */ #define RELOAD_REG_QUAD_OFFSET 0x80/* quad offset is limited. */ #define RELOAD_REG_DS_OFFSET0x100 /* bottom 2 bits must be zero. */ to be readable. So in change, I can go back to just: #define RELOAD_REG_VALID0x01/* Mode valid in register.. */ #define RELOAD_REG_MULTIPLE 0x02/* Mode takes multiple registers. */ #define RELOAD_REG_INDEXED 0x04/* Reg+reg addressing. */ #define RELOAD_REG_OFFSET 0x08/* Reg+offset addressing. */ #define RELOAD_REG_PRE_INCDEC 0x10/* PRE_INC/PRE_DEC valid. */ #define RELOAD_REG_PRE_MODIFY 0x20/* PRE_MODIFY valid. */ #define RELOAD_REG_AND_M16 0x40/* AND -16 addressing. */ #define RELOAD_REG_QUAD_OFFSET 0x80/* quad offset is limited. */ And in the next patch, change it all to: #define RELOAD_REG_VALID0x001 /* Mode valid in register.. */ #define RELOAD_REG_MULTIPLE 0x002 /* Mode takes multiple registers. */ #define RELOAD_REG_INDEXED 0x004 /* Reg+reg addressing. */ #define RELOAD_REG_OFFSET 0x008 /* Reg+offset addressing. */ #define RELOAD_REG_PRE_INCDEC 0x010 /* PRE_INC/PRE_DEC valid. */ #define RELOAD_REG_PRE_MODIFY 0x020 /* PRE_MODIFY valid. */ #define RELOAD_REG_AND_M16 0x040 /* AND -16 addressing. */ #define RELOAD_REG_QUAD_OFFSET 0x080 /* quad offset is limited. */ #define RELOAD_REG_DS_OFFSET0x100 /* bottom 2 bits must be 0. */ Some time later if I continue with the current code, that would be changed to: #define RELOAD_REG_VALID0x0001 /* 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
Re: [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h
On Sun, Jul 21, 2019 at 12:41:51PM -0500, Segher Boessenkool wrote: > On Sat, Jul 20, 2019 at 12:13:08PM -0400, Michael Meissner wrote: > > I will be iterating on patch #9 and sending out a replacement shortly. > > > > This is patch #10. It moves the various data structures from rs6000.c to > > I'll review this tomorrow, fwiw. > > A general request: please don't send patches as replies to other emails. In the past you had asked me to group patches under a single overview patch. I can go back to sending patches individually. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Re: [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h
On Sat, Jul 20, 2019 at 12:28:34PM -0400, David Edelsohn wrote: > This patch needs to add rs6000-internal.h to tm_file in gcc/config.gcc > for all of the powerpc/rs6000 targets. It also may need tm_p_file and > tm_d_file definitions. While I agree it would make things easier if the declarations are available to everybody, why wasn't this an issue when rs6000-internal.h was created to allow stuff to move out from rs6000.c to rs6000-logues.c? -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Re: [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h
Hi! On Sat, Jul 20, 2019 at 12:13:08PM -0400, Michael Meissner wrote: > 2019-07-20 Michael Meissner > > * 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_OFFSET0x0008 /* Reg+offset addressing. */ > +#define RELOAD_REG_PRE_INCDEC0x0010 /* PRE_INC/PRE_DEC valid. */ > +#define RELOAD_REG_PRE_MODIFY0x0020 /* 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
Re: [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h
On Sat, Jul 20, 2019 at 12:13:08PM -0400, Michael Meissner wrote: > I will be iterating on patch #9 and sending out a replacement shortly. > > This is patch #10. It moves the various data structures from rs6000.c to I'll review this tomorrow, fwiw. A general request: please don't send patches as replies to other emails. Segher
Re: [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h
On Sat, Jul 20, 2019 at 12:13 PM Michael Meissner
wrote:
>
> I will be iterating on patch #9 and sending out a replacement shortly.
>
> This is patch #10. It moves the various data structures from rs6000.c to
> rs6000-internal.h. In the future, it will allow us to move more things from
> rs6000.c to other files. In particular, I plan on adding a rs6000-prefixed.c
> file that has the specific support for prefixed instructions.
>
> It would also allow various functions for handling adressing and register
> assignment, etc. that could also be moved to a separate file as well.
>
> This patch just moves the data structure definitions and helper functions
> (mode_supports_*) to rs6000-internal.h. The static data structures are
> changed
> to external, and definitions of the function are put in rs6000.c. I did add
> 00
> to the bit mask definitions for RELOAD_REG_* because I plan to add at least
> one
> more mask (for DS-form addresses) in the future, and it will the values lined
> up.
>
> I have done a bootstrap on a little endian power8 system running Linux and
> there were no regressions in the test suite. Can I check this into the trunk?
This patch needs to add rs6000-internal.h to tm_file in gcc/config.gcc
for all of the powerpc/rs6000 targets. It also may need tm_p_file and
tm_d_file definitions.
Thanks, David
>
> 2019-07-20 Michael Meissner
>
> * 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. Make the static arrays
> global, and define them in rs6000.c.
> (enum rs6000_reg_type): Likewise.
> (reg_class_to_reg_type): Likewise.
> (IS_STD_REG_TYPE): Likewise.
> (IS_FP_VECT_REG_TYPE): Likewise.
> (enum rs6000_reload_reg_type): Likewise.
> (FIRST_RELOAD_REG_CLASS): Likewise.
> (LAST_RELOAD_REG_CLASS): Likewise.
> (struct reload_reg_map_type): Likewise.
> (reload_reg_map): Likewise.
> (RELOAD_REG_* macros): Likewise.
> (struct rs6000_reg_addr): Likewise.
> (reg_addr): Likewise.
> (mode_supports_pre_incdec_): Likewise.
> (mode_supports_pre_modify_p): Likewise.
> (mode_supports_vmx_dform): Likewise.
> (mode_supports_dq_form): Likewise.
> (mode_supports_prefixed_address_p): Likewise.
> * config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok_p): Likewise.
> (enum rs6000_reg_type): Likewise.
> (reg_class_to_reg_type): Likewise.
> (IS_STD_REG_TYPE): Likewise.
> (IS_FP_VECT_REG_TYPE): Likewise.
> (enum rs6000_reload_reg_type): Likewise.
> (FIRST_RELOAD_REG_CLASS): Likewise.
> (LAST_RELOAD_REG_CLASS): Likewise.
> (struct reload_reg_map_type): Likewise.
> (reload_reg_map): Likewise.
> (RELOAD_REG_* macros): Likewise.
> (struct rs6000_reg_addr): Likewise.
> (reg_addr): Likewise.
> (mode_supports_pre_incdec_): Likewise.
> (mode_supports_pre_modify_p): Likewise.
> (mode_supports_vmx_dform): Likewise.
> (mode_supports_dq_form): Likewise.
> (mode_supports_prefixed_address_p): Likewise.
>
> Index: gcc/config/rs6000/rs6000-internal.h
> ===
> --- gcc/config/rs6000/rs6000-internal.h (revision 273617)
> +++ gcc/config/rs6000/rs6000-internal.h (working copy)
> @@ -22,6 +22,134 @@
> #ifndef GCC_RS6000_INTERNAL_H
> #define GCC_RS6000_INTERNAL_H
>
> +/* Value is TRUE if register/mode pair is acceptable. */
> +extern bool rs6000_hard_regno_mode_ok_p
> + [NUM_MACHINE_MODES][FIRST_PSEUDO_REGISTER];
> +
> +/* Simplfy register classes into simpler classifications. We assume
> + GPR_REG_TYPE - FPR_REG_TYPE are ordered so that we can use a simple range
> + check for standard register classes (gpr/floating/altivec/vsx) and
> + floating/vector classes (float/altivec/vsx). */
> +
> +enum rs6000_reg_type {
> + NO_REG_TYPE,
> + PSEUDO_REG_TYPE,
> + GPR_REG_TYPE,
> + VSX_REG_TYPE,
> + ALTIVEC_REG_TYPE,
> + FPR_REG_TYPE,
> + SPR_REG_TYPE,
> + CR_REG_TYPE
> +};
> +
> +/* Map register class to register type. */
> +extern enum rs6000_reg_type reg_class_to_reg_type[N_REG_CLASSES];
> +
> +/* First/last register type for the 'normal' register types (i.e. general
> + purpose, floating point, altivec, and VSX registers). */
> +#define IS_STD_REG_TYPE(RTYPE) IN_RANGE(RTYPE, GPR_REG_TYPE, FPR_REG_TYPE)
> +
> +#define IS_FP_VECT_REG_TYPE(RTYPE) IN_RANGE(RTYPE, VSX_REG_TYPE,
> FPR_REG_TYPE)
> +
> +
> +/* 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. */
> +
> +enum rs6000_reload_reg_type
[PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h
I will be iterating on patch #9 and sending out a replacement shortly.
This is patch #10. It moves the various data structures from rs6000.c to
rs6000-internal.h. In the future, it will allow us to move more things from
rs6000.c to other files. In particular, I plan on adding a rs6000-prefixed.c
file that has the specific support for prefixed instructions.
It would also allow various functions for handling adressing and register
assignment, etc. that could also be moved to a separate file as well.
This patch just moves the data structure definitions and helper functions
(mode_supports_*) to rs6000-internal.h. The static data structures are changed
to external, and definitions of the function are put in rs6000.c. I did add 00
to the bit mask definitions for RELOAD_REG_* because I plan to add at least one
more mask (for DS-form addresses) in the future, and it will the values lined
up.
I have done a bootstrap on a little endian power8 system running Linux and
there were no regressions in the test suite. Can I check this into the trunk?
2019-07-20 Michael Meissner
* 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. Make the static arrays
global, and define them in rs6000.c.
(enum rs6000_reg_type): Likewise.
(reg_class_to_reg_type): Likewise.
(IS_STD_REG_TYPE): Likewise.
(IS_FP_VECT_REG_TYPE): Likewise.
(enum rs6000_reload_reg_type): Likewise.
(FIRST_RELOAD_REG_CLASS): Likewise.
(LAST_RELOAD_REG_CLASS): Likewise.
(struct reload_reg_map_type): Likewise.
(reload_reg_map): Likewise.
(RELOAD_REG_* macros): Likewise.
(struct rs6000_reg_addr): Likewise.
(reg_addr): Likewise.
(mode_supports_pre_incdec_): Likewise.
(mode_supports_pre_modify_p): Likewise.
(mode_supports_vmx_dform): Likewise.
(mode_supports_dq_form): Likewise.
(mode_supports_prefixed_address_p): Likewise.
* config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok_p): Likewise.
(enum rs6000_reg_type): Likewise.
(reg_class_to_reg_type): Likewise.
(IS_STD_REG_TYPE): Likewise.
(IS_FP_VECT_REG_TYPE): Likewise.
(enum rs6000_reload_reg_type): Likewise.
(FIRST_RELOAD_REG_CLASS): Likewise.
(LAST_RELOAD_REG_CLASS): Likewise.
(struct reload_reg_map_type): Likewise.
(reload_reg_map): Likewise.
(RELOAD_REG_* macros): Likewise.
(struct rs6000_reg_addr): Likewise.
(reg_addr): Likewise.
(mode_supports_pre_incdec_): Likewise.
(mode_supports_pre_modify_p): Likewise.
(mode_supports_vmx_dform): Likewise.
(mode_supports_dq_form): Likewise.
(mode_supports_prefixed_address_p): Likewise.
Index: gcc/config/rs6000/rs6000-internal.h
===
--- gcc/config/rs6000/rs6000-internal.h (revision 273617)
+++ gcc/config/rs6000/rs6000-internal.h (working copy)
@@ -22,6 +22,134 @@
#ifndef GCC_RS6000_INTERNAL_H
#define GCC_RS6000_INTERNAL_H
+/* Value is TRUE if register/mode pair is acceptable. */
+extern bool rs6000_hard_regno_mode_ok_p
+ [NUM_MACHINE_MODES][FIRST_PSEUDO_REGISTER];
+
+/* Simplfy register classes into simpler classifications. We assume
+ GPR_REG_TYPE - FPR_REG_TYPE are ordered so that we can use a simple range
+ check for standard register classes (gpr/floating/altivec/vsx) and
+ floating/vector classes (float/altivec/vsx). */
+
+enum rs6000_reg_type {
+ NO_REG_TYPE,
+ PSEUDO_REG_TYPE,
+ GPR_REG_TYPE,
+ VSX_REG_TYPE,
+ ALTIVEC_REG_TYPE,
+ FPR_REG_TYPE,
+ SPR_REG_TYPE,
+ CR_REG_TYPE
+};
+
+/* Map register class to register type. */
+extern enum rs6000_reg_type reg_class_to_reg_type[N_REG_CLASSES];
+
+/* First/last register type for the 'normal' register types (i.e. general
+ purpose, floating point, altivec, and VSX registers). */
+#define IS_STD_REG_TYPE(RTYPE) IN_RANGE(RTYPE, GPR_REG_TYPE, FPR_REG_TYPE)
+
+#define IS_FP_VECT_REG_TYPE(RTYPE) IN_RANGE(RTYPE, VSX_REG_TYPE, FPR_REG_TYPE)
+
+
+/* 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. */
+
+enum rs6000_reload_reg_type {
+ RELOAD_REG_GPR, /* General purpose registers. */
+ RELOAD_REG_FPR, /* Traditional floating point regs. */
+ RELOAD_REG_VMX, /* Altivec (VMX) registers. */
+ RELOAD_REG_ANY, /* OR of GPR, FPR, Altivec masks. */
+ N_RELOAD_REG
+};
+
+/* For setting up register classes, loop through the 3 register classes mapping
+ into real registers, and skip the ANY class,
