User Agent: Mozilla/5.0 (X11; Linux loongarch64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.217 Safari/537.36

Steps to reproduce:

According to [SMDOC] Code generation invariants, when 64-bit GPRs carrying 32-bit values, the upper bits are the sign extension of the lower bits on MIPS64, and RISCV64 may have the same feature.
But there are some operations mixed 64-bit instructions and 32-bit-instructions, and didn't maintain the invariant. Such as in MacroAssembler::prepareHashBigInt :

  loadPtr(Address(temp2, 0), temp3); 
  {
    // Compute |AddToHash(AddToHash(hash, data), sizeof(Digit))|.

#if JS_PUNBOX64
    // Hash the lower 32-bits.
    addU32ToHash(temp3); 

    // Hash the upper 32-bits.
    rshift64(Imm32(32), Register64(temp3));
    addU32ToHash(temp3);
#else
    addU32ToHash(temp3);
#endif
  }

loadPtr will load a 64-bit value to temp3 register, but addU32ToHash contains some 32-bit instructions, and needs temp3 to be a sign-extended 32-bit value.

On mips64, when 64-bit GPRs carrying 32-bit values, the upper bits are the sign extension
of the lower bits, and 32-bit instructions will check this invariant.
But on x64 and arm64, the upper bits are zero, and 32-bit instructions don't care about
the upper 32 bits of the inputs.

So when some 32-bit operations like mul32 are used, we should keep the inputs sign-extended.
And if we want a zero-extended 32-bit value, like for some bitwise operations, an explicit
zero-extension is needed.

https://hg.mozilla.org/mozilla-central/rev/428726ea261a