On arm64, Windows Performance Recorder gets confused by the fact that fp
in Builtins_JSEntry doesn't point to the saved {fp, lr} pair for the
caller frame. The expected usage of fp is documented in [1]:

  The frame pointer (x29) is required for compatibility with fast stack
  walking used by ETW and other services. It must point to the previous
  {x29, x30} pair on the stack.

In slightly more detail, the Windows function RtlWalkFrameChain is
responsible for generating stack traces during profiling with Windows
Performance Recorder, and that function relies on the rule quoted above.
Notably, it does not make any effort to read the unwinding data that one
could obtain with RtlLookupFunctionEntry. Stack walks using that data,
such as those performed by WinDbg and the cctest StackUnwindingWin64,
work fine.

It would be convenient if we could use fp in a more standard way during
JSEntry so that Windows profiling tools work correctly. (We can also
reduce JSEntry by two instructions in doing so.)

Both arm and arm64 currently put a -1 value on the stack at the location
that fp points to. This could prevent accidental access during the
epilog of JSEntry, where fp might be zero. However, we believe that this
protection is no longer necessary, and any bug that causes a read from
fp during the end of JSEntry would cause various CQ failures.

[1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160

Change-Id: Iece5666129b9188fc4c12007809b50f046f4044f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2607636
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72165}