[PATCH] Document arithmetic overflow semantics

[Michael S. Zick]

On Friday 14 February 2003 02:31 am, Fergus Henderson wrote:
> On 14-Feb-2003, Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
> > In GCC trees the signedness of additions is determined by the signedness
> > of the types of the operands.  Representing +wrap additions as unsigned
> > operations would require that the operations be converted to unsigned
> > types.
>
> Sorry, I meant s/the operations/the operands/

Actually, both.

My case for both is to generalize the internal abstraction to handle related
issues.
Since the discussion has lead to either "property bits" or "node types" to
handle overflow semantics; and somebody will be coding in this area...

I suggest adding a bit to both operator and operand to represent the
commutative property.

Multiplication ("*" operator), an operation of the second kind, would
have its commutative property bit set.

For Integer (and appropriate others) operands, they would have 
the commutative property bit set.

For Matrix operands, they would have the commutative property
bit clear.

The internal abstraction could then select its allowable optimizations
based on the commutative property bits of both operands and operators.

I.E: for;
int i1, i2 ;

i1 * i2 == i2 * i1 ;
In other words, that is allowable. (commutative == {true, true, true})

and for;
mat m1, m2 ;

m1 * m2 != m2 * m1 ;
In other words, that is NOT allowable. (commutative == {false, true, false})

With concurrent threads on this list about support for HPC and
vector types, first thing you know, somebody will want an array
of a vector type (a matrix).  Then they will expect to be able to do
basic numeric operations on them.

(Heck, perhaps bite the bullet now, add four property bits:
associative, commutative, distributive, monotonic [to support
unorder compares]).

Mike