On Mon, Oct 7, 2013 at 7:00 PM, Michael Meissner <meiss...@linux.vnet.ibm.com> wrote: > On this patch, I add some infrastructure to say whether a given mode can go in > a general purpose register, floating point register, or altivec register, and > if it can, what kinds of addressing is legal for the mode. In addition, I > have > switched to using memset to setup the arrays indexed by mode. > > I've rewritten this infrastructure since I submitted version 1 of the patch. > At present, this is only an infrastructure change, and the compiler generates > the same code underneath before and after the patch. > > I switched rs6000_legitimate_address_p so that it uses this new infrastructure > to determine if a mode can do auto update as part of the address. I found > that > the code in rs6000_legitimate_address_p was not obvious what they were trying > to do. I discovered for some 32-bit abis, the types DImode, DFmode, and > DDmode, would allow addresses with PRE_INC or PRE_DEC, but not PRE_MODIFY. At > present, I am generating the same code, but in a later patch, we can allow > PRE_MODIFY for those types as well. I noticed this when I was doing version 1 > of the patches, and I was generating more auto update addressing forms than > before. > > I have run bootstrap and make check with no regressions with these patches. I > have also tested code for various 32/64-bit targets (power8, power7, power6x, > power6, power5, power 5+, power4, cell, 476 with/with floating point, g4, g5, > e5500, e6500, and xilinx full/lite/no floating point), and I found the code > generated is identical. > > Can I install these patches in GCC 4.9 on the trunk? > > 2013-10-07 Michael Meissner <meiss...@linux.vnet.ibm.com> > > * config/rs6000/rs6000.c (enum rs6000_reload_reg_type): Add new > fields to the reg_addr array that describes the valid addressing > mode for any register, general purpose registers, floating point > registers, and Altivec registers. > (FIRST_RELOAD_REG_CLASS): Likewise. > (LAST_RELOAD_REG_CLASS): Likewise. > (struct reload_reg_map_type): Likewise. > (reload_reg_map_type): Likewise. > (RELOAD_REG_VALID): Likewise. > (RELOAD_REG_MULTIPLE): Likewise. > (RELOAD_REG_INDEXED): Likewise. > (RELOAD_REG_OFFSET): Likewise. > (RELOAD_REG_PRE_INCDEC): Likewise. > (RELOAD_REG_PRE_MODIFY): Likewise. > (reg_addr): Likewise. > (mode_supports_pre_incdec_p): New helper functions to say whether > a given mode supports PRE_INC, PRE_DEC, and PRE_MODIFY. > (mode_supports_pre_modify_p): Likewise. > (rs6000_debug_vector_unit): Rearrange the -mdebug=reg output to > print the valid address mode bits for each mode. > (rs6000_debug_print_mode): Likewise. > (rs6000_debug_reg_global): Likewise. > (rs6000_setup_reg_addr_masks): New function to set up the address > mask bits for each type. > (rs6000_init_hard_regno_mode_ok): Use memset to clear arrays. > Call rs6000_setup_reg_addr_masks to set up the address mask bits. > (rs6000_legitimate_address_p): Use mode_supports_pre_incdec_p and > mode_supports_pre_modify_p to determine if PRE_INC, PRE_DEC, and > PRE_MODIFY are supported. > (rs6000_print_options_internal): Tweak the debug output slightly.
Please use "VMX" instead of "AV", not because I am pedantic about IBM's name for the feature, but "AV" is meaningless to me and anyone else reading the code. If you need a three-letter name, use "VMX". Okay with that change. Thanks, David
