Re: [PATCH][BZ #3268] Add fma single/double implementations to soft-fp

[Steven Munroe <munroesj at us dot ibm dot com>]

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.