| Message ID | 20210429214853.GA7892@ibm-toto.the-meissners.org |
|---|---|
| State | New |
| Headers | show |
| Series | [V2] Define KFmode constants for libgcc. | expand |
Hi! On Thu, Apr 29, 2021 at 05:48:53PM -0400, Michael Meissner wrote: > This patch defines the constants needed for libgcc for the PowerPC > specific IEEE 128-bit floating point types (KFmode). It doesn't do that though? > The 4/28 changes to libgcc need these constants defined. I wondered what that means... Please write "April 28", or just use the (shortened) commit hash? > We only define the KFmode constants if IEEE 128-bit floating point is > supported, but long double does not use the IEEE 128-bit format. If long > double uses the IEEE 128-bit format, it will use TFmode and not KFmode. > > With this patch, we don't have to modify _divkc3.c to use the FLT128 > constants. Instead, the -fbuilting-libgcc option will build the appropriate > __LIBGCC_KF_* macros. That sounds good. > gcc/ > 2021-04-29 Michael Meissner <meissner@linux.ibm.com> > > PR bootstrap/100327 > * config/rs6000/rs6000.c > (TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): Define. I don't see this used anywhere on trunk? Did you forget some file(s) in the patch? Please lose the "_P", there is a verb in the name already. The name isn't good (supported for _what_? It is only for complex multiplication, right?) > (rs6000_iibgcc_floating_mode_supported_p): New target hook. Typo ("iib"). > +rs6000_libgccc_floating_mode_supported_p (scalar_float_mode mode) Typo ("gccc"). Segher
On Thu, Apr 29, 2021 at 05:50:03PM -0500, Segher Boessenkool wrote: > Hi! > > On Thu, Apr 29, 2021 at 05:48:53PM -0400, Michael Meissner wrote: > > This patch defines the constants needed for libgcc for the PowerPC > > specific IEEE 128-bit floating point types (KFmode). > > It doesn't do that though? Yes it does. With this patch and if you use -fbuilding-libgcc, it defines: __LIBGCC_KF_MAX__ __LIBGCC_KF_MIn__ __LIBGCC_KF_EPSILON__ That the new version of _divkc3.c uses. > > The 4/28 changes to libgcc need these constants defined. > > I wondered what that means... Please write "April 28", or just use the > (shortened) commit hash? Ok. > > We only define the KFmode constants if IEEE 128-bit floating point is > > supported, but long double does not use the IEEE 128-bit format. If long > > double uses the IEEE 128-bit format, it will use TFmode and not KFmode. > > > > With this patch, we don't have to modify _divkc3.c to use the FLT128 > > constants. Instead, the -fbuilting-libgcc option will build the appropriate > > __LIBGCC_KF_* macros. > > That sounds good. > > > gcc/ > > 2021-04-29 Michael Meissner <meissner@linux.ibm.com> > > > > PR bootstrap/100327 > > * config/rs6000/rs6000.c > > (TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): Define. > > I don't see this used anywhere on trunk? Did you forget some file(s) in > the patch? TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P is the name of the macro that defines the targetm.libgcc_floating_mode_supported_p hook: DEFHOOK (libgcc_floating_mode_supported_p, "Define this to return nonzero if libgcc provides support for the \n\ floating-point mode @var{mode}, which is known to pass \n\ @code{TARGET_SCALAR_MODE_SUPPORTED_P}. The default version of this \n\ hook returns true for all of @code{SFmode}, @code{DFmode}, \n\ @code{XFmode} and @code{TFmode}, if such modes exist.", bool, (scalar_float_mode mode), default_libgcc_floating_mode_supported_p) It is used in: gcc/c-family/c-cppbuiltin.c gcc/fortran/trans-types.c > Please lose the "_P", there is a verb in the name already. > > The name isn't good (supported for _what_? It is only for complex > multiplication, right?) I'm not sure what you are asking. I'm defining a standard hook. I don't have a choice of the name to use. > > (rs6000_iibgcc_floating_mode_supported_p): New target hook. > > Typo ("iib"). > > > +rs6000_libgccc_floating_mode_supported_p (scalar_float_mode mode) > > Typo ("gccc"). Ok.
On Thu, Apr 29, 2021 at 07:23:03PM -0400, Michael Meissner wrote: > On Thu, Apr 29, 2021 at 05:50:03PM -0500, Segher Boessenkool wrote: > > On Thu, Apr 29, 2021 at 05:48:53PM -0400, Michael Meissner wrote: > > > This patch defines the constants needed for libgcc for the PowerPC > > > specific IEEE 128-bit floating point types (KFmode). > > > > It doesn't do that though? > > Yes it does. With this patch and if you use -fbuilding-libgcc, it defines: > > __LIBGCC_KF_MAX__ > __LIBGCC_KF_MIn__ > __LIBGCC_KF_EPSILON__ > > That the new version of _divkc3.c uses. But you said the *patch* defines the constants. It doesn't. > > > gcc/ > > > 2021-04-29 Michael Meissner <meissner@linux.ibm.com> > > > > > > PR bootstrap/100327 > > > * config/rs6000/rs6000.c > > > (TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): Define. > > > > I don't see this used anywhere on trunk? Did you forget some file(s) in > > the patch? > > TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P is the name of the macro that defines > the targetm.libgcc_floating_mode_supported_p hook: Huh. And this is used nowhere in libgcc itself! > > The name isn't good (supported for _what_? It is only for complex > > multiplication, right?) > > I'm not sure what you are asking. I'm defining a standard hook. I don't have > a choice of the name to use. I thought it was new, because I didn't see it anywhere. I only looked in libgcc/ . Looks good then. Okay for trunk with the mentioned nits fixed. Thanks! Segher
On Thu, 29 Apr 2021, Segher Boessenkool wrote: > > > > gcc/ > > > > 2021-04-29 Michael Meissner <meissner@linux.ibm.com> > > > > > > > > PR bootstrap/100327 > > > > * config/rs6000/rs6000.c > > > > (TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): Define. > > > > > > I don't see this used anywhere on trunk? Did you forget some file(s) in > > > the patch? > > > > TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P is the name of the macro that defines > > the targetm.libgcc_floating_mode_supported_p hook: > > Huh. And this is used nowhere in libgcc itself! Target hooks can't be used directly in libgcc. It's a hook that controls macros defined if -fbuilding-libgcc is used (defining lots of predefined macros has some startup time cost, as well as creating interfaces users might then start relying on even if that's a bad idea, so if information from the compiler is only ever relevant for building its own runtime libraries and not for the normal user case, the predefined macros in question are only defined if -fbuilding-libgcc).
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index cdeb049986f..23485027d85 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -1569,6 +1569,10 @@ static const struct attribute_spec rs6000_attribute_table[] = #undef TARGET_SCALAR_MODE_SUPPORTED_P #define TARGET_SCALAR_MODE_SUPPORTED_P rs6000_scalar_mode_supported_p +#undef TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P +#define TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P \ + rs6000_libgccc_floating_mode_supported_p + #undef TARGET_VECTOR_MODE_SUPPORTED_P #define TARGET_VECTOR_MODE_SUPPORTED_P rs6000_vector_mode_supported_p @@ -24089,6 +24093,31 @@ rs6000_scalar_mode_supported_p (scalar_mode mode) return default_scalar_mode_supported_p (mode); } +/* Target hook for libgcc_floating_mode_supported_p. */ + +static bool +rs6000_libgccc_floating_mode_supported_p (scalar_float_mode mode) +{ + switch (mode) + { + case E_SFmode: + case E_DFmode: + case E_TFmode: + return true; + + /* We only return true for KFmode if IEEE 128-bit types are supported, and + if long double does not use the IEEE 128-bit format. If long double + uses the IEEE 128-bit format, it will use TFmode and not KFmode. + Because the code will not use KFmode in that case, there will be aborts + because it can't find KFmode in the Floatn types. */ + case E_KFmode: + return TARGET_FLOAT128_TYPE && !TARGET_IEEEQUAD; + + default: + return false; + } +} + /* Target hook for vector_mode_supported_p. */ static bool rs6000_vector_mode_supported_p (machine_mode mode)