This CL addresses a couple of minor issues that were in the way of
properly inlining polymorphic constructors calls, i.e. as found in
this common pattern using Symbol.species:

  class A {
    static get [Symbol.species]() { return this; }
    clone() { return new this.constructor[Symbol.species](); }
  }
  class B extends A {
    static get [Symbol.species]() { return this; }
  }

  function foo(o) { return o.clone(); }
  foo(new A());
  foo(new B());

Here the call to this.constructor[Symbol.species]() is the interesting
site. To get this fully inlined, we had to

  - make sure we don't introduce too many CheckHeapObject eagerly that
    block later optimizations (instead we try harder to see whether the
    receiver is already provably a HeapObject), and
  - also update the new.target of polymorphic JSConstruct nodes, when
    it refers to the same node as the target that we're specializing
    to (this way the JSCreate becomes fully inlinable later).

This seems to yield a solid 1.5% on the ARES6 ML benchmark (run via the
d8 cli runner), which confirms the previous profiled estimation. On the
micro-benchmark that specifically measures this feature in isolation we
go from

  testClone: 828 ms.

on V8 ToT as of today and

  testClone: 1439 ms.

on V8 6.1 to

  testClone: 219 ms.

which is a 3.7x improvement, on top of the previous ~2x boost that we
got from inlining the polymorphic symbol lookup.

Bug: v8:6885, v8:6278, v8:6344
Change-Id: Ida7abf683c7879978f181ba7f52a125f4f83ae6f
Reviewed-on: https://chromium-review.googlesource.com/700596Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48284}