tree 1a949e5446d5494e5c2803c9f67a6daa4ec82179
parent d90024d4982937c249bbbff8f02f46bfce71bb97
author Mike Klein <mtklein@google.com> 1605908056 -0600
committer Skia Commit-Bot <skia-commit-bot@chromium.org> 1605962299 +0000

remove Op::pack

pack(x,y,bits) as an alias for x|(y<<bits) only existed originally to
implement it with the SLI arm64 instruction, but I've since realized
that was misguided.

I had thought the assumption on pack ("(x & (y << bits)) == 0"), i.e.
"no overlap between x and the shifted y", was enough to make using SLI
legal, but it's actually not strong enough a requirement.

The SLI docs say "...inserts the result into the corresponding vector
element in the destination SIMD&FP register such that the new zero bits
created by the shift are not inserted but retain their existing value."
The key thing not mentioned there happens with zero bits _not_ created
by the shift, the ones already present at the top of y.  They're of
course inserted, overwriting any previous values.

This means SLI (and so pack()) become strictly order dependent in a way
I had never intended.  This will work as you'd think,

    skvm::I32 px = splat(0);
    px = pack(px, r,  0);
    px = pack(px, a, 24);

but this version swapping the two calls to pack() will overwrite alpha,

    skvm::I32 px = splat(0);
    px = pack(px, a, 24);
    px = pack(px, r,  0);

I find that error-prone, so I've removed Op::pack and replaced it
with a simple expansion to x|(y<<bits).  That of course works in either
order.

This new test can't JIT at head, but if we implement the other missing
instructions (soon, dependent CL) it would start failing when JIT'd.
The interpreter and x86 were both fine, since they're both doing what's
now the only approach to pack(), the simple x|(y<<bits).

I've left assembler support for SLI in case we want to try it again.

Change-Id: Iaf879309d3e1d0a458a688f3a62556e55ab05e23
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/337197
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>