Implement C _FloatN, _FloatNx types [version 3]

Joseph Myers joseph@codesourcery.com
Tue Aug 9 20:44:00 GMT 2016


On Tue, 9 Aug 2016, James Greenhalgh wrote:

> However, I still have some trouble with TFmode and TImode conversions. In
> particular, I'm missing support for the standard names:
> 
>   extendhftf2
>   trunctfhf2
>   floattihf2
>   fixhfti
> 
> In addition, where the ARMv8.2-A extensions are not available, I have no
> support for the standard names: 
> 
>   floatdihf
>   floatundihf
> 
> Providing these names through soft-fp in libgcc should be possible. Certainly
> I can enable extendhftf2 and trunctfhf2 using
> softfp_extensions/softfp_truncations and providing the appropriate files.
> Though, I'd rather avoid adding the full suite of soft-float routines, in
> particular I don't need arithmetic like divhf3. There are probably
> modifications I can make to the soft-fp build machinery to enable building
> only specified conversion functions.
> 
> Is this a sensible approach, or would I be better simply the full suite
> of HFmode operations that soft-fp expects?

The first question is: is using soft-fp for these operations optimal?  For 
conversions to DImode, for example, maybe converting via SFmode would be 
better when that's supported in hardware?  (That's something that would 
need to be benchmarked.)

soft-fp changes always go to glibc first, and it's now established that 
glibc gets all the soft-fp function / format implementations even those 
that are only actually used in libgcc.

HFmode support for soft-fp is at 
<https://gcc.gnu.org/ml/gcc-patches/2009-04/msg01132.html>, though of 
course it needs updating for global changes to soft-fp since then.

If you do conclude that soft-fp should be used, but only a limited set of 
functions is needed, that's what softfp_extras in t-softfp is for.

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Gcc-patches mailing list