[bigint] Fix harmless DCHECK failure

Behavior in Release mode was correct; Debug mode triggered a DCHECK
failure that indicated an inefficiency: when a requested truncation
would be a no-op, we should return the original BigInt, rather than
creating a copy. In the special case of -2^(n-1), i.e. the smallest
negative n-bit integer, getting truncated to n bits, with n being a
multiple of kDigitBits, this shortcut was not taken.

Bug: v8:8426
Change-Id: I8e4595d9ac0dbef81aae06688f9a9636bd2d9cd9
Reviewed-on: https://chromium-review.googlesource.com/c/1325029Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57369}

src/objects/bigint.cc

@@ -2155,6 +2155,8 @@ Handle<BigInt> BigInt::AsIntN(Isolate* isolate, uint64_t n, Handle<BigInt> x) {
                                                            false);
       }
     }
+    // Truncation is no-op if x == -2^(n-1).
+    if (x_length == needed_length && top_digit == compare_digit) return x;
     return MutableBigInt::TruncateToNBits(isolate, N, x);
   }
   return MutableBigInt::TruncateAndSubFromPowerOfTwo(isolate, N, x, false);

test/mjsunit/harmony/bigint/as-int-n.js

@@ -145,6 +145,10 @@
   assertEquals(-4n, BigInt.asIntN(3, "12"));
   assertEquals(0x123456789abcdefn,
                BigInt.asIntN(64, 0xabcdef0123456789abcdefn));
+}{
+  // Regression test for crbug.com/v8/8426.
+  assertEquals(-0x8000000000000000n,
+               BigInt.asIntN(64, -0x8000000000000000n));
 }
 
 // BigInt.asUintN