Fix PickLoadSigns on SignExt feature instructions (#7069)

I believe the history here is that

1.  We added a PickLoadSigns pass. It checks if a load from memory is stored in
    a local that is only every used in a signed or an unsigned manner. If it is, we can
    adjust the sign of the load (load8_u/s) to do the sign/unsign during the load.
2.  The pass finds each LocalGet and looks either 2 or 3 parents above it. For
    a sign operation, we need to look up 3, since the operation is x << K >> K. For
    an unsigned, we need only 2, since we have x & M. We hardcoded those
    numbers 2 and 3.
3.  We added the SignExt feature, which adds i32.extend8_s. This does a sign
    extend with a single instruction, not two nested ones, so now we can sign-
    extend at depth 2, unlike before. Properties::getSignExtValue was updated
    for this, but not the pass PickLoadSigns.

The bug that is fixed here is that we looked at depth 3 for a sign-extend, and
we blindly accepted it if we found one. So we ended up accepting
(i32.extend8_s (ANYTHING (x))), which is a sign-extend of something, but
not of x, which is bad.

We were also missing an optimization opportunity, as we didn't look for
depth 2 sign extends.

This bug is quite old, from when Properties got SignExt support, in #3910.
But the blame isn't there - to notice this then, we'd have had to check each
caller of getSignExtValue throughout the codebase, which isn't reasonable.
The fault is mine, from the first write-up of PickLoadSigns in 2017: the code
should have been fully general, handling 2/3 and checking the output when
it does so (adding == curr, that the sign/zero-extended value is the one we
expect). That is what this PR does.

0 files changed, 0 insertions, 0 deletions