The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Sunday, August 13, 2017

Commutative FP Addition and Multiplication

In computer arithmetic, floating point addition and multiplication cannot be associative, because of rounding.

I.e. (A+B)+C != A+(B+C)

But... FP add and multiply are frequently also not commutative, in floating point instruction sets.  Not fundamentally, not because of rounding, but because of NaN and other special value propagation.


   FADD fd := fa + fb      !=       FADD fd := fb + fa    

because, if both operands are QNaNs, the instruction set may be defined to propagate the QNaN in the first operand.

This simple rule allows compiler control - but it breaks commutativity.

Losing commutativity has several downsides:

a) the instruction set cannot use operand order to provide extra information, essentially an extra opcode bit.

b) it means that a compiler cannot freely reverse operands.

Does not matter for

   FADD fd := fa + fb      !=       FADD fd := fb + fa    

But does matter for srcdst:

   FADD fa +=fb      !=       FADD fb += fa    


Other NaN propagation rules would support commutativity.

E.g. choose the NaN whose value is smallest, if the entire NaN is interpreted as an integer bitpattern.  Or largest. Signed or unsigned.

(This may be appropriate if something like a line number is encoded in the NaN.)

E.g. merge NaN operands in some way.

No comments: