Re: [Qemu-devel] [PATCH v4 00/22] re-factor softfloat and add fp16 functions

["Alex Bennée" <alex.bennee@linaro.org>]

Laurent Vivier <laurent@vivier.eu> writes:

> Le 13/02/2018 à 16:51, Peter Maydell a écrit:
>> On 6 February 2018 at 16:47, Alex Bennée <alex.bennee@linaro.org> wrote:
>>> Hi,
>>>
>>> The main change is applying the __attribute__((flatten)) to some of
>>> the public functions that show up in Emilio's dbt-benchmark. This
>>> seems to be a cleaner solution that squashing inlines higher up the
>>> chain and still leaves the chance for re-use for the less widely used
>>> functions. The results are an improvement over v3 by some margin:
>>>
>>>                          NBench score; higher is better
>>>
>>>     5 +-+-----------+-------------+------------+-------------+-----------+-+
>>>       |                     ****### %%%%  +++                              |
>>>   4.5 +-+...................*..*..#.%..%..****##..%%%%+ system-2.5       +-+
>>>       |                     *  *  # %  %  *  * #  %  %      master         |
>>>     4 +-+...................*..*..#.%..%..*..*.#..%..%softfloat-v3       +-+
>>>   3.5 +-+...................*..*..#.%..%..*..*.#..%..%softfloat-%%%%.....+-+
>>>       |                     *  *  # %  %  *  * #  %  %  * *  #  %  %       |
>>>     3 +-+...................*..*..#.%..%..*..*.#..%..%..*.*..#..%..%.....+-+
>>>       |                     *  *  #+%  %  *  * #$$$  %  * *  #  %  %       |
>>>   2.5 +-+........####.......*..*..#$$..%..*..*.#..$..%..*.*..#..%..%.....+-+
>>>       |       ****  #  %%%  *  *  # $  %  *  * #  $  %  * *  #$$$  %       |
>>>     2 +-+.....*..*..#..%.%..*..*..#.$..%..*..*.#..$..%..*.*..#..$..%.....+-+
>>>       |       *  *  #  % %  *  *  # $  %  *  * #  $  %  * *  #  $  %       |
>>>   1.5 +-+.....*..*..#$$$.%..*..*..#.$..%..*..*.#..$..%..*.*..#..$..%.....+-+
>>>     1 +-+.....*..*..#..$.%..*..*..#.$..%..*..*.#..$..%..*.*..#..$..%.....+-+
>>>       |       *  *  #  $ %  *  *  # $  %  *  * #  $  %  * *  #  $  %       |
>>>   0.5 +-+.....*..*..#..$.%..*..*..#.$..%..*..*.#..$..%..*.*..#..$..%.....+-+
>>>       |       *  *  #  $ %  *  *  # $  %  *  * #  $  %  * *  #  $  %       |
>>>     0 +-+-----****###$$$%%--****###$$%%%--****##$$$%%%--***###$$$%%%-----+-+
>>>                  FOURIER     NEURAL NETLU DECOMPOSITION    gmean
>>>
>>> Slightly easier to read PNG:
>>>
>>>     https://i.imgur.com/XEeL0bC.png
>>>
>>> I think it's pretty ready for a merge. Shall I submit a pull myself or
>>> does it make sense going via someone else? According to MAINTAINERS
>>> Peter and Aurelien are responsible for this code...
>>
>> I had some nits but I think the best thing to do is if you fix those
>> and then just send a pull request for this.
>
> Just to be sure no one has missed that:
>
> https://bellard.org/libbf/
>
> I'm wondering if it can help for this work.

I did have a brief look through to get a sense of how it works. The
first thing it is missing however is half-precision. It only seems to
deal in 32 and 64 bit floats. The code is also fairly sparse in its
commenting.

The main approach seems to be somewhere between rth's glibc macro fest
and what we have now. It makes extensive use of every QEMU developers
favourite glue macro to instantiate code from a "template". This allows
some better usage of size appropriate types in each instantiation where
we just do most things at the highest precision.

However I think it also suffers the same problem as SoftFloat3 as in
it is not an upstream project so it is just another lump of code to
import into out code base. Based on that I favour our re-factor more as
I think it is easier to follow and hopefully will be easier to maintain.

I think we can address the inefficiencies in our mul/div code by passing
FloatFmt in and letting the compiler deal with it in each flattened
implementation. I prototyped mul:

  http://ix.io/MYw

However unless we are super worried about these inefficiencies I'm
proposing we merge what we have and deal with these in a later round.

>
> Thanks,
> Laurent


--
Alex Bennée