On Thu, Apr 28, 2016 at 05:10:07PM -0500, Segher Boessenkool wrote: > On Thu, Apr 28, 2016 at 05:06:14PM -0400, Michael Meissner wrote: > Hi Mike, > > > * config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Add > > support for __float128 complex datatypes. > > (rs6000_hard_regno_mode_ok): Likewise. > > (rs6000_setup_reg_addr_masks): Likewise. > > (rs6000_complex_function_value): Likewise. > > > > * config/rs6000/rs6000.h (FLOAT128_IEEE_P): Add support for > > __float128 and __ibm128 complex. > > (FLOAT128_IBM_P): Likewise. > > (ALTIVEC_COMPLEX): Likewise. > > (ALTIVEC_ARG_MAX_RETURN): Likewise. > > > > * doc/extend.texi (Additional Floating Types): Document that > > -mfloat128 must be used to enable __float128. Document complex > > __float128 and __ibm128 support. > > > > [gcc/testsuite] > > 2016-04-28 Michael Meissner <meiss...@linux.vnet.ibm.com> > > > > * gcc.target/powerpc/float128-complex-1.c: New test for complex > > __float128. > > It is more normal to not have blank lines between files in the changelog.
Ok. > > #define FLOAT128_IEEE_P(MODE) > > \ > > - (((MODE) == TFmode && TARGET_IEEEQUAD) \ > > - || ((MODE) == KFmode)) > > + ((TARGET_IEEEQUAD && ((MODE) == TFmode || (MODE) == TCmode)) > > \ > > + || ((MODE) == KFmode) || ((MODE) == KCmode)) > > > > #define FLOAT128_IBM_P(MODE) > > \ > > - (((MODE) == TFmode && !TARGET_IEEEQUAD) \ > > - || ((MODE) == IFmode)) > > + ((!TARGET_IEEEQUAD && ((MODE) == TFmode || (MODE) == TCmode)) > > \ > > + || ((MODE) == IFmode) || ((MODE) == ICmode)) > > Maybe these should be inline functions now? No they can't be without moving them somewhere else. The problem is if you declare them as functions machine_mode must be defined, and it isn't in a lot of cases, such as compiling the gen* functions. Even if machine_mode might eventually be defined, rs6000.h can be included for machmode.h is defined. > > +/* _Complex __float128 needs two registers. */ > > +#define ALTIVEC_COMPLEX ((TARGET_FLOAT128) ? 1 : 0) I wrote it that way to make ALTIVEC_ARG_MAX_RETURN fit in 79 columns. If you want, I can probably rework ALTIVEC_ARG_MAX_RETURN. > > This name is pretty confusing, way too generic too. It is only used > right below, you can just code it there? > > > /* Return registers */ > > #define GP_ARG_RETURN GP_ARG_MIN_REG > > #define FP_ARG_RETURN FP_ARG_MIN_REG > > #define ALTIVEC_ARG_RETURN (FIRST_ALTIVEC_REGNO + 2) > > #define FP_ARG_MAX_RETURN (DEFAULT_ABI != ABI_ELFv2 ? FP_ARG_RETURN > > \ > > : (FP_ARG_RETURN + AGGR_ARG_NUM_REG - 1)) > > -#define ALTIVEC_ARG_MAX_RETURN (DEFAULT_ABI != ABI_ELFv2 ? > > ALTIVEC_ARG_RETURN \ > > +#define ALTIVEC_ARG_MAX_RETURN (DEFAULT_ABI != ABI_ELFv2 \ > > + ? (ALTIVEC_ARG_RETURN + ALTIVEC_COMPLEX) \ > > : (ALTIVEC_ARG_RETURN + AGGR_ARG_NUM_REG - 1)) > > So you are changing the ABI here (for non-v2). Are there any complications > to that, is it compatible in all cases? I don't think so, all it is saying is we return complex float128 in 2 altivec registers. Given you could not access complex float128 before, I don't think it is an issue. Note, presently you must use -mfloat128 to enable it at all. > > > -#define PRINT_OPERAND_PUNCT_VALID_P(CODE) ((CODE) == '&') > > +#define PRINT_OPERAND_PUNCT_VALID_P(CODE) ((CODE) == '&' || (CODE) == '@') > > I think you mixed this in from another change? Yes, this is from another change. I will issue another patch tomorrow. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
