This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] ARM half-precision floating point, 3/8 (target hooks)
On Thu, 16 Apr 2009, Paolo Bonzini wrote:
>
> > The function argument and return type restrictions, and conversions from
> > double to HFmode going via float (with double rounding), are not things
> > that it's clear other targets will want; if some C and C++ interfaces to
> > half precision are standardised in future it seems likely they'd avoid
> > those restrictions; likewise the lack of _Complex __fp16. (Indeed the ARM
> > EABI defines how half-precision arguments and return types should work at
> > the language-independent ABI level; it's just the C and C++ bindings that
> > don't allow them.) If there is future standardisation it would seem
> > reasonable for the ARM implementation to align with it, possibly removing
> > some hooks.
>
> Thanks for the explanation. Then my only objections is on
> convert_to_type and promoted_type, I'm convinced that the others are
> indeed best left as target hooks.
The convert_to_type hook implements the peculiarity of the ARM C binding
that conversions from double to __fp16 go via float, and so is needed to
ensure that the same double rounding applies whether or not a conversion
is folded at compile time. (Given the hook inserting intermediate
conversions, the compiler itself should only be generating such
conversions if it knows that the double rounding cannot occur, or if
-funsafe-math-optimizations, so it should be OK for the intermediate
conversions to be inserted again whenever such conversions are seen by the
back end at a later stage.)
> BTW, is the EABI implemented for half-precision arguments and return
> types? From the 6/8 patch it does not look like and I think we should
> sorry for that in the ARM backend; even if that code is currently
> unreachable it may not be so in the future, because after Martin's
> IPA-SRA pass goes in the middle-end might decide to have a function with
> HFmode parameters or return types.
A sorry sounds like it would be a good idea - care would be needed to
ensure that whatever compiler-generated function calls it affects, it
doesn't affect the libcalls converting between HFmode and SFmode (which
are defined using unsigned short, which corresponds to how the compiler
generates code using those libcalls). Possibly the hooks determining
types that cannot be used in calls/returns should be used by any
optimization pass that might generate such functions?
AAPCS defines HFmode parameters and return types to work by converting the
values to SFmode, so implementing the AAPCS for such functions (if in
future GCC allows them to be defined) would require calls to the
conversion libcalls to be generated as part of the function calling
sequence.
--
Joseph S. Myers
joseph@codesourcery.com