Re: [PATCH] ARM half-precision floating point, 3/8 (target hooks)

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 16 Apr 2009, Paolo Bonzini wrote:

> Sandra Loosemore wrote:
> > This patch adds the target hooks that are required to get the C and
> > C++ language-level support for HFmode, specifically including the
> > implicit promotion and restrictions on function argument/return types.
> > The included documentation patch should be sufficient to explain the
> > details.
> 
> Is this necessary at all?  Can we define HFmode to be a storage-only
> type at the language level?

It's not clear to me that we have enough cases of such types to be able to 
tell what should or should not be common between the implementations for 
different architectures.  Hence the target hooks, with the possibility of 
moving more directly to the front ends in future if several targets want 
the same thing.

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.

IA64 __fpreg could equally be considered a storage-only type - it meets 
that description, but has rather different restrictions and hence uses a 
different set of hooks.  I think that illustrates the difficulty of 
defining a common "storage-only" notion at this point.

-- 
Joseph S. Myers
joseph@codesourcery.com