[turbofan] Add a Simplified::CheckMaps instruction.

[turbofan] Add a Simplified::CheckMaps instruction.

CheckMaps nodes take a receiver and a fixed number of map values as value
inputs and perform a load and a map check against the list of map values,
deoptimizing if the receiver object does not have one of the given maps.
They're essentially a compressed form of the hand-written map check that
is currently inserted by type feedback specialization. The idea is that
CheckMaps encode higher-level information that can be used in optimization
and can guard loads or stores.
They are lowered during simplified lowering to corresponding machine-level
nodes.

R=mstarzinger@chromium.org,bmeurer@chromium.org
BUG=

[Benedikt Meurer, 2015-05-20 04:18:06]

bmeurer@chromium.org changed reviewers:
+ danno@chromium.org, jarin@chromium.org, rossberg@chromium.org

[Benedikt Meurer, 2015-05-20 04:18:06]

As discussed offline yesterday, I'd be happy if we can think about this and
explore more options first. I don't think we have reached consensus about the
way we want to propagate and consume type feedback yet. And - correct me if I'm
wrong - I think we don't need to tackle this now, since we should first focus on
stuff that does not require hard deoptimization for TurboFan and especially
stuff that doesn't require embedding maps into optimized code.

So I'd vote not to land anything that goes into this direction now, and focus on
the other two areas of interest for now, namely native code execution for the
web and regular JavaScript w/o deopting/context dependencies.

[Benedikt Meurer, 2015-05-20 04:18:08]

As discussed offline yesterday, I'd be happy if we can think about this and
explore more options first. I don't think we have reached consensus about the
way we want to propagate and consume type feedback yet. And - correct me if I'm
wrong - I think we don't need to tackle this now, since we should first focus on
stuff that does not require hard deoptimization for TurboFan and especially
stuff that doesn't require embedding maps into optimized code.

So I'd vote not to land anything that goes into this direction now, and focus on
the other two areas of interest for now, namely native code execution for the
web and regular JavaScript w/o deopting/context dependencies.

[titzer, 2015-05-20 06:38:08]

On 2015/05/20 04:18:08, Benedikt Meurer wrote:
> As discussed offline yesterday, I'd be happy if we can think about this and
> explore more options first. I don't think we have reached consensus about the
> way we want to propagate and consume type feedback yet. And - correct me if
I'm
> wrong - I think we don't need to tackle this now, since we should first focus
on
> stuff that does not require hard deoptimization for TurboFan and especially
> stuff that doesn't require embedding maps into optimized code.

I agree that we need to pursue context-independent compilation to make cacheable
code. But the other long term strategy is to generate better code than
CrankShaft for the throughput benchmarks, and we'll need to use many of the same
tricks.

> So I'd vote not to land anything that goes into this direction now, and focus
on
> the other two areas of interest for now, namely native code execution for the
> web and regular JavaScript w/o deopting/context dependencies.

This a mechanism CL, not a policy CL. As mentioned above, we'll want to do
guarded fast property loads that deopt on failure in the future. We'll also want
to do guarded fast property loads that have a slow path in the nearer future.
The policy for which guards (that deopt) to insert and where (currently in
JSTypeFeedbackSpecialization) based on what feedback needs some work. That's
longer term, but having the mechanism in place, tested would be nice.