[PATCH][BZ #3268] Add fma single/double implementations to soft-fp
Steven Munroe
munroesj@us.ibm.com
Fri Oct 13 13:48:00 GMT 2006
Jakub Jelinek wrote:
>On Thu, Oct 12, 2006 at 11:47:06AM -0500, Steven Munroe wrote:
>
>>--- libc25-cvstip-20061005/soft-fp/fmadf4.c Wed Dec 31 18:00:00 1969
>>+++ libc24/soft-fp/fmadf4.c Tue Oct 10 09:54:48 2006
>>
>...
>
>>+#include "soft-fp.h"
>>+#include "double.h"
>>+#include "quad.h"
>>
>...
>
>>+ long double u, x, y, z;
>>
>...
>
>>+ FP_PACK_RAW_Q(x,X);
>>+ FP_PACK_RAW_Q(y,Y);
>>+ FP_PACK_RAW_Q(z,Z);
>>+ FP_HANDLE_EXCEPTIONS;
>>+
>>+ /* Multiply.
>>+ Rounding is not an issue as we keep the full 106 bit product. */
>>+ FP_UNPACK_Q(X,x);
>>+ FP_UNPACK_Q(Y,y);
>>+ FP_MUL_Q(U,X,Y);
>>+ FP_PACK_Q(u,U);
>>+ FP_HANDLE_EXCEPTIONS;
>>+
>>+ /* Add without rounding. */
>>+ FP_UNPACK_SEMIRAW_Q(U,u);
>>
>
>This isn't generic enough, not all targets have quad long double.
>While in software it is possible to have IEEE quad support, when the
>C long double type is shorter, such value should never go into that type.
>
hhhmmm would it help to declare
+ QItype u, x, y, z;
where
typedef int QItype __attribute__ ((mode (QI)));
Or is this also platform dependent?
>So, I think you need to use _FP_PACK_CANONICAL/_FP_UNPACK_CANONICAL
>
We tried this in the earlier implementations but had problems where
extranious bits where left on in the expanded form. This is why we need:
+#if (2 * _FP_W_TYPE_SIZE) < _FP_FRACBITS_Q
+ V_f[3] &= 0x0007ffff; /* SEMIRAW_TO_SEMIRAW(4) */
Between the FP_SUB and FP_TRUNC. Here we could not use the full
PACK/UNPACK because it would cause double rounding. What you suggest
will require more extensive work to create special macros like
_FP_SEMIRAW_TO_SEMIRAW_Q and _FP_CANONICAL_TO_SEMIRAW_Q etc. This can be
done but it will be a while before I can get to it (day job you know).
>instead (which AFAIK does everything you need here). Also, comments
>about 106 bits aren't appropriate even for IEEE quad.
>
>
Actually this is correct as is. Multiplying two 53 bit (with implicit
bit) signifcands of two doubles produces a 106 product, indepentent of
long double format.
More information about the Libc-alpha
mailing list