While reading through the jump threading implementation, I noticed
something strange: ApplyForwarding iterates through the block list in
reverse post-order, not in assembly order. Thus, the value prev_fallthru
might not refer to the previous block in assembly order. Obviously it
works fine this way or we would have noticed by now, but I think that
this step would be a little easier to read and reason about if the
iteration used assembly order instead.

I've added a test case to demonstrate the difference when using
assembly order: in a diamond where the right side starts with an empty
deferred block, the current implementation would fail to replace that
block with a nop. I doubt this case would have any real-world impact.

Change-Id: I28abe2043434debb54896871d15c540ad52c6368
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3039261
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76067}