[compiler] Add baseline tier to compilation pipeline.

[compiler] Add baseline tier to compilation pipeline.

This adds a baseline tier to the compilation pipeline. Currently this
tier is used to model a path from the interpreter to optimized code via
full-codegen code (to ensure sufficient type feedback). Switching from
the unoptimized tier to the baseline tier is limited to happen only when
there are no activations of the given function on the stack.

R=rmcilroy@chromium.org,bmeurer@chromium.org

Committed: https://crrev.com/3fc0224cfc65a238ed83b6a4823f2eae0060aabf
Cr-Commit-Position: refs/heads/master@{#35757}

[Michael Starzinger, 2016-04-22 08:37:35]

Description was changed from

==========
[compiler] Add baseline tier to compilation pipeline.

This adds a baseline tier to the compilation pipeline. Currently this
tier is used to model a path from the interpreter to optimized code via
full-codegen code (to ensure sufficient type feedback). Switching from
the unoptimized tier to the baseline tier is limited to happen only when
there are no activations of the given function on the stack.

R=
==========

to

==========
[compiler] Add baseline tier to compilation pipeline.

This adds a baseline tier to the compilation pipeline. Currently this
tier is used to model a path from the interpreter to optimized code via
full-codegen code (to ensure sufficient type feedback). Switching from
the unoptimized tier to the baseline tier is limited to happen only when
there are no activations of the given function on the stack.

R=rmcilroy@chromium.org,bmeurer@chromium.org
==========

[Michael Starzinger, 2016-04-22 08:37:36]

mstarzinger@chromium.org changed reviewers:
+ bmeurer@chromium.org, rmcilroy@chromium.org

[Benedikt Meurer, 2016-04-22 09:17:04]

Nice. LGTM from my side.

[rmcilroy, 2016-04-22 10:02:57]

Nice, LGTM with a couple of optional suggestions.

https://codereview.chromium.org/1903273004/diff/40001/src/compiler.cc
File src/compiler.cc (right):

https://codereview.chromium.org/1903273004/diff/40001/src/compiler.cc#newcode875
src/compiler.cc:875: for (; !it.done(); it.Advance()) {
Also done when "has_activations_" ?

https://codereview.chromium.org/1903273004/diff/40001/src/compiler.cc#newcode902
src/compiler.cc:902: // might have created a copy of the bytecode with break
slots.
Is this a TODO - I though we were planning to always do this?

https://codereview.chromium.org/1903273004/diff/40001/src/compiler.cc#newcode938
src/compiler.cc:938: // Compile unoptimized code using the full code generator.
/s/unoptimzed/baseline

https://codereview.chromium.org/1903273004/diff/40001/src/objects.cc
File src/objects.cc (right):

https://codereview.chromium.org/1903273004/diff/40001/src/objects.cc#newcode1...
src/objects.cc:11976: isolate->builtins()->builtin(Builtins::kCompileBaseline));
Should we have a flag --no-baseline or --no-full-codegen or similar (like
--no-crankshaft) so we can disable baseline compilation. (The check should
probably live in compiler.cc, not here though).

https://codereview.chromium.org/1903273004/diff/40001/src/runtime-profiler.cc
File src/runtime-profiler.cc (right):

https://codereview.chromium.org/1903273004/diff/40001/src/runtime-profiler.cc...
src/runtime-profiler.cc:109: if (function->shared()->HasBytecodeArray()) {
Maybe we could have a function on SharedFunctionInfo which gives back the
current optimization tier (unoptimized, baseline, optimized) and use that rather
than checking for a bytecode array (which we might eventually keep around even
after optimizing). I'm fine with doing this at a later point though.

[Michael Starzinger, 2016-04-22 10:47:45]

Thanks! Addressed comments. I might wait with landing this till Monday though,
because I don't want ClusterFuzz to go berserk over the weekend.

https://codereview.chromium.org/1903273004/diff/40001/src/compiler.cc
File src/compiler.cc (right):

https://codereview.chromium.org/1903273004/diff/40001/src/compiler.cc#newcode875
src/compiler.cc:875: for (; !it.done(); it.Advance()) {
On 2016/04/22 10:02:57, rmcilroy wrote:
> Also done when "has_activations_" ?

Done.

https://codereview.chromium.org/1903273004/diff/40001/src/compiler.cc#newcode902
src/compiler.cc:902: // might have created a copy of the bytecode with break
slots.
On 2016/04/22 10:02:57, rmcilroy wrote:
> Is this a TODO - I though we were planning to always do this?

Done. I don't have a concrete answer on whether we ever want to be able to debug
functions that are running in "unoptimized" as well as "baseline" code at the
same time. For now we certainly don't, you are right, hence removed the TODO.

https://codereview.chromium.org/1903273004/diff/40001/src/compiler.cc#newcode938
src/compiler.cc:938: // Compile unoptimized code using the full code generator.
On 2016/04/22 10:02:57, rmcilroy wrote:
> /s/unoptimzed/baseline

Done.

https://codereview.chromium.org/1903273004/diff/40001/src/objects.cc
File src/objects.cc (right):

https://codereview.chromium.org/1903273004/diff/40001/src/objects.cc#newcode1...
src/objects.cc:11976: isolate->builtins()->builtin(Builtins::kCompileBaseline));
On 2016/04/22 10:02:57, rmcilroy wrote:
> Should we have a flag --no-baseline or --no-full-codegen or similar (like
> --no-crankshaft) so we can disable baseline compilation. (The check should
> probably live in compiler.cc, not here though).

Acknowledged. Yes, totally agree. I also want to add a --always-baseline (or
similarly named) flag that stressed tiering up to baseline code. I plan to add
this in a follow-up CL. And yes, I agree, the check for this flag should live in
compiler.cc (or the runtime profiler), definitely not here.

https://codereview.chromium.org/1903273004/diff/40001/src/runtime-profiler.cc
File src/runtime-profiler.cc (right):

https://codereview.chromium.org/1903273004/diff/40001/src/runtime-profiler.cc...
src/runtime-profiler.cc:109: if (function->shared()->HasBytecodeArray()) {
On 2016/04/22 10:02:57, rmcilroy wrote:
> Maybe we could have a function on SharedFunctionInfo which gives back the
> current optimization tier (unoptimized, baseline, optimized) and use that
rather
> than checking for a bytecode array (which we might eventually keep around even
> after optimizing). I'm fine with doing this at a later point though.

Acknowledged. Good idea, totally agree. I am not sure if we should make this a
predicate on the SharedFunctionInfo though, because it could only discriminate
"unoptimized" and "baseline". Only a concrete closure (i.e. JSFunction) can be
"optimized". So it might make sense to have the entire family of predicates only
on JSFunction. I'll dwell a bit over that and will implement in a follow-up CL.

[Michael Starzinger, 2016-04-25 10:23:16]

The CQ bit was checked by mstarzinger@chromium.org

[Michael Starzinger, 2016-04-25 10:23:17]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, rmcilroy@chromium.org
Link to the patchset: https://codereview.chromium.org/1903273004/#ps60001
(title: "Addressed comments.")

[commit-bot: I haz the power, 2016-04-25 10:23:24]

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

[commit-bot: I haz the power, 2016-04-25 10:46:44]

Description was changed from

==========
[compiler] Add baseline tier to compilation pipeline.

This adds a baseline tier to the compilation pipeline. Currently this
tier is used to model a path from the interpreter to optimized code via
full-codegen code (to ensure sufficient type feedback). Switching from
the unoptimized tier to the baseline tier is limited to happen only when
there are no activations of the given function on the stack.

R=rmcilroy@chromium.org,bmeurer@chromium.org
==========

to

==========
[compiler] Add baseline tier to compilation pipeline.

This adds a baseline tier to the compilation pipeline. Currently this
tier is used to model a path from the interpreter to optimized code via
full-codegen code (to ensure sufficient type feedback). Switching from
the unoptimized tier to the baseline tier is limited to happen only when
there are no activations of the given function on the stack.

R=rmcilroy@chromium.org,bmeurer@chromium.org
==========

[commit-bot: I haz the power, 2016-04-25 10:46:45]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-04-25 10:48:49]

Description was changed from

==========
[compiler] Add baseline tier to compilation pipeline.

This adds a baseline tier to the compilation pipeline. Currently this
tier is used to model a path from the interpreter to optimized code via
full-codegen code (to ensure sufficient type feedback). Switching from
the unoptimized tier to the baseline tier is limited to happen only when
there are no activations of the given function on the stack.

R=rmcilroy@chromium.org,bmeurer@chromium.org
==========

to

==========
[compiler] Add baseline tier to compilation pipeline.

This adds a baseline tier to the compilation pipeline. Currently this
tier is used to model a path from the interpreter to optimized code via
full-codegen code (to ensure sufficient type feedback). Switching from
the unoptimized tier to the baseline tier is limited to happen only when
there are no activations of the given function on the stack.

R=rmcilroy@chromium.org,bmeurer@chromium.org

Committed: https://crrev.com/3fc0224cfc65a238ed83b6a4823f2eae0060aabf
Cr-Commit-Position: refs/heads/master@{#35757}
==========

[commit-bot: I haz the power, 2016-04-25 10:48:50]

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