RFC: Enabling fixed point modes on x86

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Enabling fixed point modes on x86

Martin Ling
Hi all, new to the list.

Attached is a very short patch which enables the use of fixed point
modes on x86 targets. I first created this a couple of years ago for
gcc 7 and have just updated it for current git master.

I have not sent this to the patches list as I do not expect it to be
anywhere near merge-ready. Rather, I was hoping to have a conversation
about what is missing and what else might need to be done for fixed
point modes to become officially supported on x86, or whether that's
even desirable.

My initial motivation for this was that we have a C codebase primarily
written for an embedded ARM target with no FPU, which makes extensive
use of the fract/accum types available on that target. To simplify
development we wanted to be able to build & test this code on
x86 systems. Performance (on x86) was not a concern for us.

Although I had no prior knowlede of gcc internals/development I started
looking at what might be needed to enable fixed point support on x86,
and it seems like very little is needed for it to work:

gcc/config/i386/i386.c:

- classify_argument() needs to classify the *Q and *A modes as per their
  corresponding integer modes.

- ix86_scalar_mode_supported_p needs to forward to
  default_fixed_point_supported_p for ALL_SCALAR_FIXED_POINT_MODE_P.

gcc/configure[.ac]:

- allow --enable-fixed-point for i?86* and x86_64*

With these changes, everything seems to "just work". The fixed point
helper functions in libgcc/fixed-bit.c are built automatically for all
the possible mode combinations, and get linked in as needed by the
resulting compiler. The tests in gcc/testsuite/gcc.dg/fixed-point pass.

Of course, everything is emulated - no special instruction sequences are
generated, and the resulting code is probably no faster than could be
achieved using libfixmath or similar libraries.

But even without a performance advantage this is useful - it allows
compatibility with fixed point code written for other platforms, and
enables fixed point code to be written more clearly on x86, by use of
special types rather than library functions.

I am guessing however that there is a lot more that needs to be thought
about before anything like this could be merged.

For starters, by doing this I have implicitly invented an ABI for fixed
point types on x86 (they get passed exactly like correspondingly-sized
integers, I suppose). This ABI would be unique to gcc.

I have also implicitly set the numbers of integral and fractional bits
for each mode to the gcc defaults (which are specified in the docs at
https://gcc.gnu.org/onlinedocs/gccint/Machine-Modes.html).

I don't know the x86 instruction set (and its many extensions) well, and
haven't thought about how fixed point operations could be implemented
most efficiently with it, and whether that would affect the choice of
format for each mode.

And yet, this works and is useful (to us at least).

What else have I missed? What else would be needed for this to be
supported? And does anyone see any value in adding this, or should I
just keep this to myself as an out of tree patch?

Regards,


Martin

gcc-x86-fixed-point.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Enabling fixed point modes on x86

Joseph Myers
On Mon, 30 Sep 2019, Martin Ling wrote:

> For starters, by doing this I have implicitly invented an ABI for fixed
> point types on x86 (they get passed exactly like correspondingly-sized
> integers, I suppose). This ABI would be unique to gcc.
>
> I have also implicitly set the numbers of integral and fractional bits
> for each mode to the gcc defaults (which are specified in the docs at
> https://gcc.gnu.org/onlinedocs/gccint/Machine-Modes.html).

Yes - and we had the discussion at the Cauldron recently about trying to
coordinate ABIs for new features with anyone who might wish to support
those in other implementations.

In the case of x86, there are ABI mailing lists [hidden email]
and [hidden email] that can be consulted (though they don't
always come to a conclusion when issues are raised, it's probably
necessary to be quite active about pushing things to a conclusion and
getting it into the ABI repositories).

I should also mention the concern I previously expressed that the present
implementation approach for fixed-point support in GCC is questionable and
it might be better to have GIMPLE lowering of fixed-point types to normal
integer ones, with some extra GIMPLE operations but without separate
machine modes <https://gcc.gnu.org/ml/gcc-patches/2011-05/msg00846.html>.  
This is not however intended to block addition of fixed-point support to
any architecture based on the existing approach, given that we don't have
an implementation based on such lowering (and the same ABI issues would
still apply this this approach).

--
Joseph S. Myers
[hidden email]