[turbofan]: Integrate basic type feedback for property accesses.

src/flag-definitions.h

Index: src/flag-definitions.h
diff --git a/src/flag-definitions.h b/src/flag-definitions.h
index c9ac7b57b70d54c5733b22da512eb653efbd5fb5..6f433c954fa91a2350eafa28946055987dd788c3 100644
--- a/src/flag-definitions.h
+++ b/src/flag-definitions.h
@@ -400,9 +400,11 @@ DEFINE_BOOL(turbo_verify, DEBUG_BOOL, "verify TurboFan graphs at each phase")
 DEFINE_BOOL(turbo_stats, false, "print TurboFan statistics")
 DEFINE_BOOL(turbo_splitting, true, "split nodes during scheduling in TurboFan")
 DEFINE_BOOL(turbo_types, true, "use typed lowering in TurboFan")
+DEFINE_BOOL(turbo_type_feedback, false, "use type feedback in TurboFan")
 DEFINE_BOOL(turbo_source_positions, false,
             "track source code positions when building TurboFan IR")
 DEFINE_IMPLICATION(trace_turbo, turbo_source_positions)
+DEFINE_IMPLICATION(turbo_type_feedback, turbo_deoptimization)

[titzer, 2015/03/24 10:49:32]

Comments on this? Should type feedback imply deoptimization support? We could
still support fast path map checks and guarded inlining without deoptimizing,
but nothing that requires code dependencies.

[Michael Starzinger, 2015/03/24 12:11:18]

Agreed, it would be nice to be able to leverage dynamic feedback even without
deoptimization support. Not sure if we ever want to run in such a mode, but it
would be nice to know that we could. :)

[titzer, 2015/03/24 14:52:06]

I removed the implication and put a branch in js-type-feedback.cc

 DEFINE_BOOL(context_specialization, false,
             "enable context specialization in TurboFan")
 DEFINE_BOOL(turbo_deoptimization, false, "enable deoptimization in TurboFan")