Software FP Support

Software FP Support

[Paulo J. Matos]

Hi,

I am trying to get FP support working in a backend. This raised
several questions which were promptly answered and after digging
deeper I found the culprit.
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.

Now, I read in http://gcc.gnu.org/wiki/Software_floating_point that
soft-fp doesn't support 16bit targets, but (even if slow) does fp-bit
support 16bit target?
I just need a rudimentary floating point support (speed is not
important) and I am trying to avoid assembler.

Would I be able to get it working with fp-bit or maybe setting the
FLOAT_TYPE_SIZE to something different than 32?

-- 
PMatos

Re: Software FP Support

[Joseph S. Myers]

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.

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).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Software FP Support

[Paulo J. Matos]

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

Re: Software FP Support

[Paulo J. Matos]

On Tue, Mar 30, 2010 at 2:29 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> 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.
>
> 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).
>

Hello Joseph, let me add something to my last email.
From your email I get the feeling that you can explicitly enable the
HFmode, how can I check if this is being done?

On a surprising note, I decided to try and compile it with
FLOAT_TYPE_SIZE with 64 bits, therefore a float should not be SFmode
and the floatunsihf shouldn't be generated anymore. I was wrong, it is
still generated.

Where are these function calls generated in gcc? (I would expect it to
be during the expand pass but have no idea of where exactly)

-- 
PMatos

Re: Software FP Support

[Paulo J. Matos]

On Tue, Mar 30, 2010 at 2:54 PM, Paulo J. Matos <pocmatos@gmail.com> wrote:
>
> On a surprising note, I decided to try and compile it with
> FLOAT_TYPE_SIZE with 64 bits, therefore a float should not be SFmode
> and the floatunsihf shouldn't be generated anymore. I was wrong, it is
> still generated.
>

This is false, I forgot to regenerate the assembler for the file I was
testing on. In this case, it does change the call to a floatunsisf, as
expected. However, this is not practical for my purposes. It still
makes more sense to me to have float as 32bits.


-- 
PMatos

Re: Software FP Support

[Joseph S. Myers]

On Tue, 30 Mar 2010, Paulo J. Matos wrote:

> 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

The GCC support for BITS_PER_UNIT values other than 8 is extremely 
bitrotten and parts of it have never worked; there are no such targets in 
the GCC source tree, no patches are tested for such targets and it is easy 
to have hidden dependencies on 8-bit bytes.  It is very inadvisable to 
make your first port one to such an unusual target; substantially more GCC 
experience and expertise is needed for doing a port to a system different 
from all supported systems and that challenges hidden assumptions in the 
GCC code.  There will be a large amount of work finding and fixing issues 
related to non-8-bit bytes that will need doing before you have a working 
integer port, and all that should be done before you look at 
floating-point issues.

If seriously interested in fixing support for non-8-bit bytes, first 
understand exactly what the C semantics are for such systems (including 
how strings are meant to work).  Then read my various past messages to the 
GCC lists discussing aspects of support for such systems in GCC (which you 
should be able to find for yourself in the list archives).  Improving wide 
string support for normal 8-bit-byte systems (so that optimization etc. 
infrastructure can work with both wide and narrow strings) may be a useful 
starting point for making some things work when the characters in narrow 
strings are more than one host byte.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Software FP Support

[Paulo J. Matos]

On Tue, Mar 30, 2010 at 3:29 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Tue, 30 Mar 2010, Paulo J. Matos wrote:
>
>> 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
>
> The GCC support for BITS_PER_UNIT values other than 8 is extremely
> bitrotten and parts of it have never worked; there are no such targets in
> the GCC source tree, no patches are tested for such targets and it is easy
> to have hidden dependencies on 8-bit bytes.  It is very inadvisable to
> make your first port one to such an unusual target; substantially more GCC
> experience and expertise is needed for doing a port to a system different
> from all supported systems and that challenges hidden assumptions in the
> GCC code.  There will be a large amount of work finding and fixing issues
> related to non-8-bit bytes that will need doing before you have a working
> integer port, and all that should be done before you look at
> floating-point issues.
>
> If seriously interested in fixing support for non-8-bit bytes, first
> understand exactly what the C semantics are for such systems (including
> how strings are meant to work).  Then read my various past messages to the
> GCC lists discussing aspects of support for such systems in GCC (which you
> should be able to find for yourself in the list archives).  Improving wide
> string support for normal 8-bit-byte systems (so that optimization etc.
> infrastructure can work with both wide and narrow strings) may be a useful
> starting point for making some things work when the characters in narrow
> strings are more than one host byte.

Thank you for all the discussion regarding the GCC support to 16bit
targets. I had noticed already issues with wide-char strings which was
another pending subject. :)
I will be careful with gcc in this respect and make sure I start
fixing issues regarding 'unusual' 16bit targets.


-- 
PMatos