x64's implementation of i64x2.shr_s was overwriting the scratch
register. kScratchRegister is used to hold the extracted lane of the
SIMD register, but in certain cases [0], is also used to back up the
value of rcx. When this happens, the supposed backed-up rcx was
overwritten (definitely) by each extract lane, so we end up restoring
an incorrect value of rcx, leading to an eventual crash in certain
benchmarks, when this extracted lane was used as a memory operand (see
linked bugs).

[0] when register holding the shift value is not rcx, which sarq_cl
relies on

Bug: v8:10752
Bug: chromium:1111522
Change-Id: Iaf3264e16f94e78bad4290783757f0b722d40411
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2334354Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69208}