This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
This patch makes some changes to the way the PowerPC handles IEEE 128-bit floating point, and I wanted to point out where I would like to change the compiler, but be open to doing it in other ways. There are 3 changes in this patch, and presumably more work to do beyond this patch. The first change is to enable the C language to use _Float128 keyword (but not __float128) without having to use the -mfloat128 option on power7-power9 systems. My question is in the TR that introduced _Float128, is there any expectation that outside of the built-in functions we already provide, that we need to provide runtime functions? Yes, glibc 2.26 will be coming along shortly, and it should provide most/all of the F128 functions, but distros won't pick this library up for some time. I would like to enable it, but I want to avoid the problem that we have with __float128 in that once the keyword is supported, it is assumed everything is supported. GCC and GLIBC run on different cycles (and different people work on it), and so you typically have to have GCC add support before GLIBC can use it. We've discovered that boost and libstdc++ both assume the full library support exists if the __float128 keyword is used. We will eventually need to tackle both of these libraries, but we need to the full GLIBC support (or libquadmath) to provide this functionality. Part of the reason for wanting to enable _Float128 without library support or an explicit -mfloat128 is the types and built-in functions have to be set up at compiler startup, and it makes the second change simpler. The second change is to allow #pragma GCC target and attribute((target(...))) to enable IEEE 128-bit __float128 on a per module basis (PR 70589). If I don't enable _Float128 unconditionally, I've discovered that I couldn't find a way to allow _Float128 access after compiler startup. In the second change, I changed how we handle __float128 internally. Previously, we would create the keyword __float128 if -mfloat128, and we would create the same type with the undocumented __ieee128 keyword (you need a keyword to enable the type). Now, I always create the __ieee128 keyword, and if -mfloat128 (or pragma/attribute) is enabled, I add a define: #define __float128 __ieee128 It was a lot simpler to do it this way, rather than trying to keep track of whether the real keyword was __float128 or __ieee128, and do the appropriate define or undef. The third change is to add cpu names 'power7f', 'power8f', and 'power9f' that enable the appropriate power<n> architecture but also does a -mfloat128. The motavation here is you cannot use either #pragma GCC target anywhere or the target attribute on the function with a target_clones attribute declaration. The question is do people see the need for -mcpu=power9f? Or should those be dropped? Assuming we are keeping those, is there a name people prefer instead of just using a 'f' suffix. Note, the GCC infrastructure does not allow a hyphen in the name in creating configargs.h for --with-cpu=<xxx>, etc. At the current time, you cannot use --with-cpu=power8f (it fails in configuring libstdc++, which says that GLIBC supports __float128), but as GLIBC 2.26 becomes more refined, hopefully it will work someday. In writing the tests, I discovered two of the float128 tests could have the target requiements/options tweaked, and I included those changes here. I also discovered we had parallel bits for setting up power7, and I used the ISA 2.06 mask in the power7 definition. So comments on how to proceed? [gcc] 2017-07-20 Michael Meissner <meissner@linux.vnet.ibm.com> PR target/70589 * config.gcc (powerpc*-*-*): Add support for -mcpu=power{7,8,9}f that combines -mcpu=power{7,8,9} with -mfloat128. * config/rs6000/rs6000-cpus.def (OTHER_IEEE_SW_MASKS): New mask of the float128 software/hardware options. (OTHER_IEEE_HW_MASKS): Likewise. (power7 cpu): Replace masks with ISA_2_6_MASKS_SERVER. (power7f): New cpu target that combines a particular machine with -mfloat128. (power8f): Likewise. (power9f): Likewise. * config/rs6000/rs6000-tables.opt: Regenerate. * config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Add support for allowing -mfloat128 to be enabled via target pragma or attribute. Always use __ieee128 for the IEEE 128-bit floating point internal type, and if -mfloat128, add a define from __float128 to __ieee128. (rs6000_cpu_cpp_builtins): Likewise. * config/rs6000/rs6000.c (rs6000_init_builtins): Enable _Float128 if -mfloat128-type is enabled (on by default for VSX systems) rather than -mfloat128 (which controls __float128). (rs6000_floatn_mode): Likewise. (rs6000_opt_masks): Allow float128 and float128-hardware target options to be set. * doc/invoke.texi (PowerPC options): Document -mcpu=power{7,8,9}f. [gcc/testsuite] 2017-07-20 Michael Meissner <meissner@linux.vnet.ibm.com> PR target/70589 * gcc/testsuite/gcc.target/powerpc/float128-3.c: New test. * gcc/testsuite/gcc.target/powerpc/float128-4.c: Likewise. * gcc/testsuite/gcc.target/powerpc/float128-5.c: Likewise. * gcc/testsuite/gcc.target/powerpc/float128-1.c: Fix test to just use -mvsx instead of hardwiring the cpu to power7. Delete the option -static-libgcc, which is not needed. * gcc/testsuite/gcc.target/powerpc/float128-2.c: Likewise. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Attachment:
pr70589.patch03b
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |