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]

[PATCH, RFC] Proposed PowerPC IEEE 128-bit floating point changes


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]