Re: Remove LIBGCC2_HAS_?F_MODE target macros
On Fri, 12 Sep 2014, paul_kon...@dell.com wrote: > > * SFmode would always have been supported in libgcc (the condition was > > BITS_PER_UNIT == 8, true for all current targets), but pdp11 > > defaults to 64-bit float, and in that case SFmode would fail > > scalar_mode_supported_p. I don't know if libgcc actually built for > > pdp11 (and the port may well no longer be being used), but this > > patch adds a scalar_mode_supported_p hook to it to ensure SFmode is > > treated as supported. > > I thought it does build. I continue to work to keep that port alive. > > The change looks fine. > > The ideal solution, I think, would be to handle the choice of float > length that the pdp11 target has via the multilib machinery. Currently > it does not do that. If multilib were added for that at some point, > would that require a change of the code in that hook? I think the ideal is for the back end to accept a mode in scalar_mode_supported_p if it can generate something sensible (either inline code or calls to libgcc functions) for arithmetic on that mode, rather than ICEs or otherwise invalid code, even if the libgcc functions don't actually exist. (Thus, ix86_scalar_mode_supported_p always considers TFmode to be supported, whether or not the libgcc support is present.) On that basis, my hook to treat SFmode as always supported for pdp11 (so it can be accessed with __attribute__((mode(SF))), whether or not it's also float) seems to be the right thing. (Various back ends would, if they adopted my ideal, then also need to add the libgcc_floating_mode_supported_p hook to indicate the conditional lack of libgcc support for certain modes. E.g. for several back ends, TFmode is only supported in libgcc if it's long double, and most of the runtime support is expected to be in libc not libgcc, under symbol names from some ABI for that architecture. In those cases, building in the libgcc support for e.g. __multc3 in the absence of libc support would be problematic, because it would reference undefined libc functions.) -- Joseph S. Myers jos...@codesourcery.com
Re: Remove LIBGCC2_HAS_?F_MODE target macros
On Sep 11, 2014, at 9:22 PM, Joseph S. Myers wrote:
> This patch removes the LIBGCC2_HAS_{SF,DF,XF,TF}_MODE target macros,
> replacing them by predefines with -fbuilding-libgcc, together with a
> target hook that can influence those predefines when needed.
>
> The new default is that a floating-point mode is supported in libgcc
> if (a) it passes the scalar_mode_supported_p hook (otherwise it's not
> plausible for it to be supported in libgcc) and (b) it's one of those
> four modes (since those are the modes for which libgcc hardcodes the
> possibility of support). The target hook can override the default
> choice (in either direction) for modes that pass
> scalar_mode_supported_p (although overriding in the direction of
> returning true when the default would return false only makes sense if
> all relevant functions are specially defined in libgcc for that
> particular target).
>
> The previous default settings depended on various settings such as
> LIBGCC2_LONG_DOUBLE_TYPE_SIZE, as well as targets defining the above
> target macros if the default wasn't correct.
>
> The default scalar_mode_supported_p only declares a floating-point
> mode to be supported if it matches one of float / double / long
> double. This means that in most cases where a mode is only supported
> conditionally in libgcc (TFmode only supported if it's the mode of
> long double, most commonly), the default gets things right. Overrides
> were needed in the following cases:
>
> * SFmode would always have been supported in libgcc (the condition was
> BITS_PER_UNIT == 8, true for all current targets), but pdp11
> defaults to 64-bit float, and in that case SFmode would fail
> scalar_mode_supported_p. I don't know if libgcc actually built for
> pdp11 (and the port may well no longer be being used), but this
> patch adds a scalar_mode_supported_p hook to it to ensure SFmode is
> treated as supported.
I thought it does build. I continue to work to keep that port alive.
The change looks fine.
The ideal solution, I think, would be to handle the choice of float length that
the pdp11 target has via the multilib machinery. Currently it does not do
that. If multilib were added for that at some point, would that require a
change of the code in that hook?
paul
Re: Remove LIBGCC2_HAS_?F_MODE target macros
On Fri, Sep 12, 2014 at 3:22 AM, Joseph S. Myers
wrote:
> This patch removes the LIBGCC2_HAS_{SF,DF,XF,TF}_MODE target macros,
> replacing them by predefines with -fbuilding-libgcc, together with a
> target hook that can influence those predefines when needed.
>
> The new default is that a floating-point mode is supported in libgcc
> if (a) it passes the scalar_mode_supported_p hook (otherwise it's not
> plausible for it to be supported in libgcc) and (b) it's one of those
> four modes (since those are the modes for which libgcc hardcodes the
> possibility of support). The target hook can override the default
> choice (in either direction) for modes that pass
> scalar_mode_supported_p (although overriding in the direction of
> returning true when the default would return false only makes sense if
> all relevant functions are specially defined in libgcc for that
> particular target).
>
> The previous default settings depended on various settings such as
> LIBGCC2_LONG_DOUBLE_TYPE_SIZE, as well as targets defining the above
> target macros if the default wasn't correct.
>
> The default scalar_mode_supported_p only declares a floating-point
> mode to be supported if it matches one of float / double / long
> double. This means that in most cases where a mode is only supported
> conditionally in libgcc (TFmode only supported if it's the mode of
> long double, most commonly), the default gets things right. Overrides
> were needed in the following cases:
>
> * SFmode would always have been supported in libgcc (the condition was
> BITS_PER_UNIT == 8, true for all current targets), but pdp11
> defaults to 64-bit float, and in that case SFmode would fail
> scalar_mode_supported_p. I don't know if libgcc actually built for
> pdp11 (and the port may well no longer be being used), but this
> patch adds a scalar_mode_supported_p hook to it to ensure SFmode is
> treated as supported.
>
> * Certain i386 and ia64 targets need the new hook to match the
> existing cases for when XFmode or TFmode support is present in
> libgcc. For i386, the hook can always declare XFmode to be
> supported - the cases where it's not are the cases where long double
> is TFmode, in which case XFmode fails scalar_mode_supported_p[*] -
> but TFmode support needs to be conditional. (And of the targets not
> defining LIBGCC2_HAS_TF_MODE before this patch, some defined
> LONG_DOUBLE_TYPE_SIZE to 64, so ensuring LIBGCC2_HAS_TF_MODE would
> always be false, while others did not define it, so allowing it to
> be true in the -mlong-double-128 case. This patch matches that
> logic, although I suspect all the latter targets would have been
> broken if you tried to enable -mlong-double-128 by default, for lack
> of the soft-fp TFmode support in libgcc, which is separately
> configured.)
>
> [*] I don't know if it's deliberate not to support __float80 at all
> with -mlong-double-128.
>
> In order to implement the default version of the new hook,
> insn-modes.h was made to contain macros such as HAVE_TFmode for each
> machine mode, so the default hook can contain conditionals on whether
> XFmode and TFmode exist (to match the hardcoding of a list of modes in
> libgcc). This is also used in fortran/trans-types.c; previously it
> had a conditional on defined(LIBGCC2_HAS_TF_MODE) (a bit dubious,
> since it ignored the value of the macro), which is replaced by testing
> defined(HAVE_TFmode), in conjunction with requiring
> targetm.libgcc_floating_mode_supported_p.
>
> (Fortran is testing something stronger than that hook: not only is
> libgcc support required, but also libm or equivalent. Thus, it has a
> test for ENABLE_LIBQUADMATH_SUPPORT in the case that the mode is
> TFmode and that's not the same as any of the three standard types.
> The old and new tests are intended to accept exactly the same set of
> modes for all targets.)
>
> Apart from the four target macros eliminated by this patch, it gets us
> closer to eliminating LIBGCC2_LONG_DOUBLE_TYPE_SIZE as well, though a
> few more places using that macro need changing first.
>
> Bootstrapped with no regressions on x86_64-unknown-linux-gnu; also
> built cc1 for crosses to ia64-elf and pdp11-none as a minimal test of
> changes for those targets. OK to commit?
Ok.
Thanks,
Richard.
> gcc:
> 2014-09-11 Joseph Myers
>
> * target.def (libgcc_floating_mode_supported_p): New hook.
> * targhooks.c (default_libgcc_floating_mode_supported_p): New
> function.
> * targhooks.h (default_libgcc_floating_mode_supported_p): Declare.
> * doc/tm.texi.in (LIBGCC2_HAS_DF_MODE, LIBGCC2_HAS_XF_MODE)
> (LIBGCC2_HAS_TF_MODE): Remove.
> (TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): New @hook.
> * doc/tm.texi: Regenerate.
> * genmodes.c (emit_insn_modes_h): Define HAVE_%smode for each
> machine mode.
> * system.h (LIBGCC2_HAS_SF_MODE, LIBGCC2_HAS_DF_MODE)
> (LIBGCC2_HAS_XF_MODE, LIBGCC
Remove LIBGCC2_HAS_?F_MODE target macros
This patch removes the LIBGCC2_HAS_{SF,DF,XF,TF}_MODE target macros,
replacing them by predefines with -fbuilding-libgcc, together with a
target hook that can influence those predefines when needed.
The new default is that a floating-point mode is supported in libgcc
if (a) it passes the scalar_mode_supported_p hook (otherwise it's not
plausible for it to be supported in libgcc) and (b) it's one of those
four modes (since those are the modes for which libgcc hardcodes the
possibility of support). The target hook can override the default
choice (in either direction) for modes that pass
scalar_mode_supported_p (although overriding in the direction of
returning true when the default would return false only makes sense if
all relevant functions are specially defined in libgcc for that
particular target).
The previous default settings depended on various settings such as
LIBGCC2_LONG_DOUBLE_TYPE_SIZE, as well as targets defining the above
target macros if the default wasn't correct.
The default scalar_mode_supported_p only declares a floating-point
mode to be supported if it matches one of float / double / long
double. This means that in most cases where a mode is only supported
conditionally in libgcc (TFmode only supported if it's the mode of
long double, most commonly), the default gets things right. Overrides
were needed in the following cases:
* SFmode would always have been supported in libgcc (the condition was
BITS_PER_UNIT == 8, true for all current targets), but pdp11
defaults to 64-bit float, and in that case SFmode would fail
scalar_mode_supported_p. I don't know if libgcc actually built for
pdp11 (and the port may well no longer be being used), but this
patch adds a scalar_mode_supported_p hook to it to ensure SFmode is
treated as supported.
* Certain i386 and ia64 targets need the new hook to match the
existing cases for when XFmode or TFmode support is present in
libgcc. For i386, the hook can always declare XFmode to be
supported - the cases where it's not are the cases where long double
is TFmode, in which case XFmode fails scalar_mode_supported_p[*] -
but TFmode support needs to be conditional. (And of the targets not
defining LIBGCC2_HAS_TF_MODE before this patch, some defined
LONG_DOUBLE_TYPE_SIZE to 64, so ensuring LIBGCC2_HAS_TF_MODE would
always be false, while others did not define it, so allowing it to
be true in the -mlong-double-128 case. This patch matches that
logic, although I suspect all the latter targets would have been
broken if you tried to enable -mlong-double-128 by default, for lack
of the soft-fp TFmode support in libgcc, which is separately
configured.)
[*] I don't know if it's deliberate not to support __float80 at all
with -mlong-double-128.
In order to implement the default version of the new hook,
insn-modes.h was made to contain macros such as HAVE_TFmode for each
machine mode, so the default hook can contain conditionals on whether
XFmode and TFmode exist (to match the hardcoding of a list of modes in
libgcc). This is also used in fortran/trans-types.c; previously it
had a conditional on defined(LIBGCC2_HAS_TF_MODE) (a bit dubious,
since it ignored the value of the macro), which is replaced by testing
defined(HAVE_TFmode), in conjunction with requiring
targetm.libgcc_floating_mode_supported_p.
(Fortran is testing something stronger than that hook: not only is
libgcc support required, but also libm or equivalent. Thus, it has a
test for ENABLE_LIBQUADMATH_SUPPORT in the case that the mode is
TFmode and that's not the same as any of the three standard types.
The old and new tests are intended to accept exactly the same set of
modes for all targets.)
Apart from the four target macros eliminated by this patch, it gets us
closer to eliminating LIBGCC2_LONG_DOUBLE_TYPE_SIZE as well, though a
few more places using that macro need changing first.
Bootstrapped with no regressions on x86_64-unknown-linux-gnu; also
built cc1 for crosses to ia64-elf and pdp11-none as a minimal test of
changes for those targets. OK to commit?
gcc:
2014-09-11 Joseph Myers
* target.def (libgcc_floating_mode_supported_p): New hook.
* targhooks.c (default_libgcc_floating_mode_supported_p): New
function.
* targhooks.h (default_libgcc_floating_mode_supported_p): Declare.
* doc/tm.texi.in (LIBGCC2_HAS_DF_MODE, LIBGCC2_HAS_XF_MODE)
(LIBGCC2_HAS_TF_MODE): Remove.
(TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): New @hook.
* doc/tm.texi: Regenerate.
* genmodes.c (emit_insn_modes_h): Define HAVE_%smode for each
machine mode.
* system.h (LIBGCC2_HAS_SF_MODE, LIBGCC2_HAS_DF_MODE)
(LIBGCC2_HAS_XF_MODE, LIBGCC2_HAS_TF_MODE): Poison.
* config/i386/cygming.h (LIBGCC2_HAS_TF_MODE): Remove.
* config/i386/darwin.h (LIBGCC2_HAS_TF_MODE): Remove.
* config/i386/djgpp.h (IX86_MAYBE_NO_LIBGCC_TFMODE): Define.
* config/i386/dragonfly.h
