[Interpreter] Avoid binding bytecode_array to a variable in CallEpilogue

[Interpreter] Avoid binding bytecode_array to a variable in CallEpilogue

Binding bytecode_array to a CodeStubAssembler variable in CallEpilogue
was causing issues with the approach to inline code stubs into
interpreter bytecode handlers. Instead of doing this, just keep track of
whether a call has been made, and if so reload directly from the stack
frame when necessary.

BUG=v8:4280
LOG=N

Committed: https://crrev.com/4e4fa66fa1cd10dcc4ef56ad9f94b4acfc8037ed
Cr-Commit-Position: refs/heads/master@{#35586}

[rmcilroy, 2016-04-18 14:20:07]

rmcilroy@chromium.org changed reviewers:
+ epertoso@chromium.org

[rmcilroy, 2016-04-18 14:20:08]

Enrico, PTAL, thanks.

[epertoso, 2016-04-18 14:23:27]

https://codereview.chromium.org/1895063002/diff/1/src/interpreter/interpreter...
File src/interpreter/interpreter-assembler.cc (right):

https://codereview.chromium.org/1895063002/diff/1/src/interpreter/interpreter...
src/interpreter/interpreter-assembler.cc:89: return LoadRegister(
You probably want to reset made_call_ to false here.

[rmcilroy, 2016-04-18 14:59:15]

https://codereview.chromium.org/1895063002/diff/1/src/interpreter/interpreter...
File src/interpreter/interpreter-assembler.cc (right):

https://codereview.chromium.org/1895063002/diff/1/src/interpreter/interpreter...
src/interpreter/interpreter-assembler.cc:89: return LoadRegister(
On 2016/04/18 14:23:27, epertoso wrote:
> You probably want to reset made_call_ to false here.

No I don't think so, if we did that then if there was a branch after the call
where both sides of the branch do a Dispatch (e.g., the Jump bytecodes), then
setting this to false here would make one side of the branch get the reloaded
value, while the other would get the value in the parameter - both should get
the reloaded version if the handler made a call.

As mentioned offline, we get a new interpreter assembler for every bytecode
handler, so this should be ok.

[epertoso, 2016-04-18 15:00:58]

lgtm

[rmcilroy, 2016-04-18 15:02:05]

The CQ bit was checked by rmcilroy@chromium.org

[commit-bot: I haz the power, 2016-04-18 15:02:09]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1895063002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1895063002/1

[commit-bot: I haz the power, 2016-04-18 15:23:35]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-04-18 15:25:10]

Description was changed from

==========
[Interpreter] Avoid binding bytecode_array to a variable in CallEpilogue

Binding bytecode_array to a CodeStubAssembler variable in CallEpilogue
was causing issues with the approach to inline code stubs into
interpreter bytecode handlers. Instead of doing this, just keep track of
whether a call has been made, and if so reload directly from the stack
frame when necessary.

BUG=v8:4280
LOG=N
==========

to

==========
[Interpreter] Avoid binding bytecode_array to a variable in CallEpilogue

Binding bytecode_array to a CodeStubAssembler variable in CallEpilogue
was causing issues with the approach to inline code stubs into
interpreter bytecode handlers. Instead of doing this, just keep track of
whether a call has been made, and if so reload directly from the stack
frame when necessary.

BUG=v8:4280
LOG=N

Committed: https://crrev.com/4e4fa66fa1cd10dcc4ef56ad9f94b4acfc8037ed
Cr-Commit-Position: refs/heads/master@{#35586}
==========

[commit-bot: I haz the power, 2016-04-18 15:25:11]

Patchset 1 (id:??) landed as
https://crrev.com/4e4fa66fa1cd10dcc4ef56ad9f94b4acfc8037ed
Cr-Commit-Position: refs/heads/master@{#35586}