Optimize AOT's switchable calls for the monomorphic case.

Optimize AOT's switchable calls for the monomorphic case.

The call sequence is very similar to a classic IC call, except the guarded class and the target are loaded indirectly from the constant pool instead of as immediates. In the monomorphic case, we call directly to the expected target with a class check in the callee. In the unlinked, polymorphic and megamorphic cases, we call a stub; these case are now call-through instead of call-and-return.

Every code, except stubs involved in switchable calls, includes the class check sequence at the beginning. So we now distinguish between a checked and an unchecked entry point. Generated code except the switchable call continues to use the unchecked entry point.

PC offsets are calculated relative to the beginning of the instruction stream, rather than either entry point.

BUG=
R=fschneider@google.com

Committed: https://github.com/dart-lang/sdk/commit/7ff2dd4117f076adb09d3330be3afd1355eada8b

[rmacnak, 2016-08-09 22:45:07]

Description was changed from

==========
classic ic call
==========

to

==========
Optimize AOT's switchable calls for the monomorphic case.

The call sequence is very similar to a classic IC call, except the target is
loaded indirectly from the constant pool instead of as a load immediate. In the
monomorphic case, we call directly to the expected target with a class check in
the callee. In the unlinked, polymorphic and megamorphic cases, we call a stub;
these case are now call-through instead of call-and-return.

Every code, except stubs involved in switchable calls, includes the class check
sequence at the beginning. So we now distinguish between a checked and an
unchecked entry point. Generated code except the switchable call continues to
use the unchecked entry point.

PC offsets are calculated relative to the beginning of the instruction stream,
rather than either entry point.
==========

[rmacnak, 2016-08-09 22:47:46]

Description was changed from

==========
Optimize AOT's switchable calls for the monomorphic case.

The call sequence is very similar to a classic IC call, except the target is
loaded indirectly from the constant pool instead of as a load immediate. In the
monomorphic case, we call directly to the expected target with a class check in
the callee. In the unlinked, polymorphic and megamorphic cases, we call a stub;
these case are now call-through instead of call-and-return.

Every code, except stubs involved in switchable calls, includes the class check
sequence at the beginning. So we now distinguish between a checked and an
unchecked entry point. Generated code except the switchable call continues to
use the unchecked entry point.

PC offsets are calculated relative to the beginning of the instruction stream,
rather than either entry point.
==========

to

==========
Optimize AOT's switchable calls for the monomorphic case.

The call sequence is very similar to a classic IC call, except the guarded class
and the target are loaded indirectly from the constant pool instead of as
immediates. In the monomorphic case, we call directly to the expected target
with a class check in the callee. In the unlinked, polymorphic and megamorphic
cases, we call a stub; these case are now call-through instead of
call-and-return.

Every code, except stubs involved in switchable calls, includes the class check
sequence at the beginning. So we now distinguish between a checked and an
unchecked entry point. Generated code except the switchable call continues to
use the unchecked entry point.

PC offsets are calculated relative to the beginning of the instruction stream,
rather than either entry point.

BUG=
==========

[rmacnak, 2016-08-09 23:28:27]

Description was changed from

==========
Optimize AOT's switchable calls for the monomorphic case.

The call sequence is very similar to a classic IC call, except the guarded class
and the target are loaded indirectly from the constant pool instead of as
immediates. In the monomorphic case, we call directly to the expected target
with a class check in the callee. In the unlinked, polymorphic and megamorphic
cases, we call a stub; these case are now call-through instead of
call-and-return.

Every code, except stubs involved in switchable calls, includes the class check
sequence at the beginning. So we now distinguish between a checked and an
unchecked entry point. Generated code except the switchable call continues to
use the unchecked entry point.

PC offsets are calculated relative to the beginning of the instruction stream,
rather than either entry point.

BUG=
==========

to

==========
Optimize AOT's switchable calls for the monomorphic case.

The call sequence is very similar to a classic IC call, except the guarded class
and the target are loaded indirectly from the constant pool instead of as
immediates. In the monomorphic case, we call directly to the expected target
with a class check in the callee. In the unlinked, polymorphic and megamorphic
cases, we call a stub; these case are now call-through instead of
call-and-return.

Every code, except stubs involved in switchable calls, includes the class check
sequence at the beginning. So we now distinguish between a checked and an
unchecked entry point. Generated code except the switchable call continues to
use the unchecked entry point.

PC offsets are calculated relative to the beginning of the instruction stream,
rather than either entry point.

BUG=
==========

[rmacnak, 2016-08-09 23:28:59]

rmacnak@google.com changed reviewers:
+ fschneider@google.com

[Florian Schneider, 2016-08-10 02:32:14]

LGTM

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/code_genera...
File runtime/vm/code_generator.cc (right):

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/code_genera...
runtime/vm/code_generator.cc:1046: Smi& old_guarded_cid = Smi::Handle(zone);
To avoid overlapping terminology, maybe rename guarded_cid to cached_cid? We
already have guarded_cid for field type tracking.

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/native_argu...
File runtime/vm/native_arguments.h (right):

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/native_argu...
runtime/vm/native_arguments.h:115: RawObject** arg_ptr = &(argv_[index]);
Since this is not used on DBC, maybe rather make it UNREACHABLE()?

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/object.h
File runtime/vm/object.h (right):

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/object.h#ne...
runtime/vm/object.h:3983: static const intptr_t kCheckedEntryOffset = 3*4;
n*Instr::kInstrSize on ARM, ARM64, and MIPS.

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/object.h#ne...
runtime/vm/object.h:4029: static RawInstructions* FromEntryPoint(uword
entry_point) {
rename to FromUncheckedEntryPoint?

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/precompiler.cc
File runtime/vm/precompiler.cc (right):

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/precompiler...
runtime/vm/precompiler.cc:1939: if (ic_.NumArgsTested() != 1) continue;
I wonder about this: We don't have fast paths for all binary smi ops. Do we need
this?

With your CL, the fast-path smi stubs could probably be removed, if we make sure
we have intrinsic code for these operations.

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/profiler.cc
File runtime/vm/profiler.cc (right):

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/profiler.cc...
runtime/vm/profiler.cc:1265: // BOGUS?
Left-over?

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/stub_code_x...
File runtime/vm/stub_code_x64.cc (right):

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/stub_code_x...
runtime/vm/stub_code_x64.cc:2179: __ pushq(RDI);                          //
Arg0: Receiver / stub out
formatting: align //

[rmacnak, 2016-08-11 00:17:49]

X64: Don't use LoadClassIdMayBeSmi, which destroys the object register if it is
smi
All: Don't transition to monomorphic while precompiling to prevent hiding an
instance call from the tree shaker.
All: Update other switchable call stub comments to remove call about returned
entry point.
MIPS: Remove leftover print

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/code_genera...
File runtime/vm/code_generator.cc (right):

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/code_genera...
runtime/vm/code_generator.cc:1046: Smi& old_guarded_cid = Smi::Handle(zone);
On 2016/08/10 02:32:14, Florian Schneider wrote:
> To avoid overlapping terminology, maybe rename guarded_cid to cached_cid? We
> already have guarded_cid for field type tracking.

=> expected_cid

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/native_argu...
File runtime/vm/native_arguments.h (right):

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/native_argu...
runtime/vm/native_arguments.h:115: RawObject** arg_ptr = &(argv_[index]);
On 2016/08/10 02:32:14, Florian Schneider wrote:
> Since this is not used on DBC, maybe rather make it UNREACHABLE()?

Remove altogether after removing monomorphic case while in the middle of
precompiling.

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/object.h
File runtime/vm/object.h (right):

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/object.h#ne...
runtime/vm/object.h:3983: static const intptr_t kCheckedEntryOffset = 3*4;
On 2016/08/10 02:32:14, Florian Schneider wrote:
> n*Instr::kInstrSize on ARM, ARM64, and MIPS.

Done.

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/object.h#ne...
runtime/vm/object.h:4029: static RawInstructions* FromEntryPoint(uword
entry_point) {
On 2016/08/10 02:32:14, Florian Schneider wrote:
> rename to FromUncheckedEntryPoint?

Done.

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/profiler.cc
File runtime/vm/profiler.cc (right):

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/profiler.cc...
runtime/vm/profiler.cc:1265: // BOGUS?
On 2016/08/10 02:32:14, Florian Schneider wrote:
> Left-over?

Renamed as Start

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/stub_code_x...
File runtime/vm/stub_code_x64.cc (right):

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/stub_code_x...
runtime/vm/stub_code_x64.cc:2179: __ pushq(RDI);                          //
Arg0: Receiver / stub out
On 2016/08/10 02:32:14, Florian Schneider wrote:
> formatting: align //

Done.

[rmacnak, 2016-08-11 00:19:13]

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/precompiler.cc
File runtime/vm/precompiler.cc (right):

https://codereview.chromium.org/2226893002/diff/150001/runtime/vm/precompiler...
runtime/vm/precompiler.cc:1939: if (ic_.NumArgsTested() != 1) continue;
On 2016/08/10 02:32:14, Florian Schneider wrote:
> I wonder about this: We don't have fast paths for all binary smi ops. Do we
need
> this?
> 
> With your CL, the fast-path smi stubs could probably be removed, if we make
sure
> we have intrinsic code for these operations.

Seeing at least some zero-arg IC here that are suspicous

  ICData target:'identical' num-args: 0 num-checks: 1

[rmacnak, 2016-08-12 18:18:40]

Description was changed from

==========
Optimize AOT's switchable calls for the monomorphic case.

The call sequence is very similar to a classic IC call, except the guarded class
and the target are loaded indirectly from the constant pool instead of as
immediates. In the monomorphic case, we call directly to the expected target
with a class check in the callee. In the unlinked, polymorphic and megamorphic
cases, we call a stub; these case are now call-through instead of
call-and-return.

Every code, except stubs involved in switchable calls, includes the class check
sequence at the beginning. So we now distinguish between a checked and an
unchecked entry point. Generated code except the switchable call continues to
use the unchecked entry point.

PC offsets are calculated relative to the beginning of the instruction stream,
rather than either entry point.

BUG=
==========

to

==========
Optimize AOT's switchable calls for the monomorphic case.

The call sequence is very similar to a classic IC call, except the guarded class
and the target are loaded indirectly from the constant pool instead of as
immediates. In the monomorphic case, we call directly to the expected target
with a class check in the callee. In the unlinked, polymorphic and megamorphic
cases, we call a stub; these case are now call-through instead of
call-and-return.

Every code, except stubs involved in switchable calls, includes the class check
sequence at the beginning. So we now distinguish between a checked and an
unchecked entry point. Generated code except the switchable call continues to
use the unchecked entry point.

PC offsets are calculated relative to the beginning of the instruction stream,
rather than either entry point.

BUG=
R=fschneider@google.com

Committed:
https://github.com/dart-lang/sdk/commit/7ff2dd4117f076adb09d3330be3afd1355eada8b
==========

[rmacnak, 2016-08-12 18:18:42]

Committed patchset #12 (id:210001) manually as
7ff2dd4117f076adb09d3330be3afd1355eada8b.