i32.neg and i32.not operations

[yurydelendik]

I cannot find a decision at the issue tracker about integer bitwise-not and negate operators. Could you clarify the intent to not include these in MVP?

[titzer]

They are easily expressible as "i32.sub(0, x)" and "i32.xor(x, -1)", which,
given short encodings for -1 and 0, are simple and space-efficient to
encode.

On Tue, Sep 29, 2015 at 5:09 PM, Yury Delendik notifications@github.com
wrote:

I cannot find a decision at the issue tracker about integer bitwise-not
and negate operators. Could you clarify the intent to not include these in
MVP?

—
Reply to this email directly or view it on GitHub
#379.

[jcbeyler]

Though when I follow this conversation:
#362

It seems that the consensus is that we can add some opcodes without too much difficulty; so should we not just add the right opcodes instead of using these alternatives. Especially since we could then live without having those extra constants encoded.

[lukewagner]

i32.not is actually a bit too high-level since it loses whether the input is actually only 0 or 1 (in which case the xor works) or any i32 (which requires a test;sete, i.e., i32.eq(x, 0)). Note that the PR to add bool does add a bool.not.

I don't have any real strong opinion on i32.neg. Since x86 actually has a a neg op, to avoid yet-another-pattern-match, I'd be inclined to have i32.neg, esp. since we already have practically all the other comparison ops.

[titzer]

I also agree that we shouldn't add the i32.not or i32.neg operators, since we have the full complement of integer comparisons and therefore inverting a branch might be more efficient if the application knows whether the input is really a bool or an i32, and therefore could choose xor vs == 0.