This is the mail archive of the 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]

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 

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]