This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Software FP Support
On Tue, Mar 30, 2010 at 2:29 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Tue, 30 Mar 2010, Paulo J. Matos wrote:
>
>> GCC is generating a call to floatunsihf when it needs to convert an
>> unsigned integer to a float. And this call is being generated because
>> I am compiling to a 16bit target, where floats are 32, meaning floats
>> are HFmode.
>
> No, HFmode only exists if you specifically define it to exist for a
> target. ÂUnless you really know what you are doing, you should not define
> it until you have ordinary float (SFmode) working. ÂIf HFmode calls are
> generated without having defined it as a target-specific mode, something
> is wrong you need to resolve.
>
I didn't define the HFmode but gcc still generates this call (reason is below).
> The basic unit for machine modes is QImode, meaning one byte -
> BITS_PER_UNIT bits (8 bits unless you know exactly what you are doing and
> are prepared to fix many broken and bit-rotten cases in
> machine-independent code). ÂHImode and HFmode are modes of 2*BITS_PER_UNIT
> bits. ÂSImode and SFmode are modes of 4*BITS_PER_UNIT bits. ÂSo presuming
> BITS_PER_UNIT is 8, a 32-bit float should be SFmode; a 16-bit integer
> value should be HImode (for any target with 8-bit bytes, whatever the word
> size).
>
I have 16 BITS_PER_UNIT for this target, with 1 UNITS_PER_WORD. If I
define FLOAT_TYPE_SIZE to be 32, then a float is an HFmode and it's
not that gcc uses this.
Defining BITS_PER_UNIT to 16 shouldn't generate problems inside the
compiler given that GCC has generic treatment for these situations
(otherwise GCC should state that only BITS_PER_UNIT=8 is supported).
The problem is how to integrate software floating point support for
this target where a float is not SFmode 'as usual'.
> --
> Joseph S. Myers
> joseph@codesourcery.com
>
--
PMatos