Word{8,32}.neg

[Matthew Fluet]

I've started investigating what optimizations can be eliminated from the
backend.  I have two peephole optimizations called elimBinAL0L elimBinAL0R
which correspond to rewriting binary arithmetic/logic instructions with 0
on the left or right.  Almost all of these went away with Steve's new
cps-shrinker.  The one case remaining is the following:

z = Word{8,32}_sub(0x0, x) 

which the backend turns into a simple negation.  The shrinker can't make
that optimization because there isn't a Word{8,32}_neg primitive.  

Up to this time, I would guess, the set of primitives have been guided by
operations in the basis-library that couldn't be expressed efficiently in
SML in terms of other more basic primitives.  I say efficiently because
MLton choose to make Real_sin, etc. as primitives, as opposed to using a
Taylor expansion the way SML/NJ did up until a month ago.  In many cases,
(as in Real_sin and most of the arithmetic/logics), we could exploit
native instructions.  We might now begin considering expanding the set of
primitives to include operations that can be expressed efficiently at the
instruction level, even if they don't have a corresponding counterpart in
the basis-library.  The motivating example in this case being a
Word{8,32}_neg primitive.  I'd also argue for Word{8,32} rotate
primitives, but I'll hold off on that until I actually compare the running
times of a rotate to the pair of shifts and an or.