[turbofan] Initial support for polymorphic inlining.
For call sites where the target is not a known constant, but potentially a list of known constants (i.e. a Phi with all HeapConstant inputs), we still record the call site as a potential candidate for inlining. In case the heuristic picks that candidate for inlining, we expand the call site to a dispatched call site and invoke the actual inlining logic for all the nested call sites. Like Crankshaft, we currently allow up to 4 targets for polymorphic inlining, although we might want to refine that later. This approach is different from what Crankshaft does in that we don't duplicate the evaluation of the parameters per polymorphic case. Instead we first perform the load of the target (which usually dispatches based on the receiver map), then we evaluate all the parameters, and then we dispatch again based on the known targets. This might generate better or worse code compared to what Crankshaft does, and for the cases where we generate worse code (i.e. because we have only trivial parameters or no parameters at all), we might want to investigate optimizing away the double dispatch in the future. R=mvstanton@chromium.org BUG=v8:5267,v8:5365 Review-Url: https://codereview.chromium.org/2325943002 Cr-Commit-Position: refs/heads/master@{#39302}
Showing
This diff is collapsed.
Please
register
or
sign in
to comment