Codegen for super.x and super[x]

Codegen for super.x and super[x]

BUG=v8:3330
LOG=N
R=verwaest@chromium.org,arv@chromium.org

[Dmitry Lomov (no reviews), 2014-08-20 21:58:44]

Toon, Erik, 
please take initial look.
This is based on https://codereview.chromium.org/475423003/, not for landing
yet.
Only full-codegen ia32 for now.
Just checking if you like it, anything I am missing?

[arv (Not doing code reviews), 2014-08-20 22:16:36]

Is this correctly handling getters?

function Base() {}
Derived.prototype = {
  constructor: Base,
  get x() {
    return this._x;
  },
  _x: 'base'
};

function Derived() {}
Derived.__proto__ = Base;
Derived.prototype = {
  __proto__: Base.prototype,
  constructor: Derived,
  testGetter: function() {
    return super.x;
  }.toMethod(Derived.prototype),
  _x: 'derived'  
};

assertEquals('derived', new Derived().testGetter());

[Dmitry Lomov (no reviews), 2014-08-20 22:33:25]

On 2014/08/20 22:16:36, arv wrote:
> Is this correctly handling getters?
> 
> function Base() {}
> Derived.prototype = {
>   constructor: Base,
>   get x() {
>     return this._x;
>   },
>   _x: 'base'
> };
> 
> function Derived() {}
> Derived.__proto__ = Base;
> Derived.prototype = {
>   __proto__: Base.prototype,
>   constructor: Derived,
>   testGetter: function() {
>     return super.x;
>   }.toMethod(Derived.prototype),
>   _x: 'derived'  
> };
> 
> assertEquals('derived', new Derived().testGetter());

No, you are right.

[Dmitry Lomov (no reviews), 2014-08-20 22:57:56]

On 2014/08/20 22:33:25, Dmitry Lomov (chromium) wrote:
> On 2014/08/20 22:16:36, arv wrote:
> > Is this correctly handling getters?
> > 
> > function Base() {}
> > Derived.prototype = {
> >   constructor: Base,
> >   get x() {
> >     return this._x;
> >   },
> >   _x: 'base'
> > };
> > 
> > function Derived() {}
> > Derived.__proto__ = Base;
> > Derived.prototype = {
> >   __proto__: Base.prototype,
> >   constructor: Derived,
> >   testGetter: function() {
> >     return super.x;
> >   }.toMethod(Derived.prototype),
> >   _x: 'derived'  
> > };
> > 
> > assertEquals('derived', new Derived().testGetter());
> 
> No, you are right.

Oh my, looks like to really optimize this. we would need new ICs (smth like
LoadSuperIC, with 3 arguments: lookup start, object and name; same for
StoreSuperIC; repeat 2x Keyed). Also of course in super.x() x might be a getter
as well, oh my. Let me know if you see a simpler solution.

As a first approximation, I can just generate runtime calls.

[Dmitry Lomov (no reviews), 2014-08-21 08:22:08]

On 2014/08/20 22:57:56, Dmitry Lomov (chromium) wrote:

> 
> Oh my, looks like to really optimize this. we would need new ICs (smth like
> LoadSuperIC, with 3 arguments: lookup start, object and name; same for
> StoreSuperIC; repeat 2x Keyed). Also of course in super.x() x might be a
getter
> as well, oh my. Let me know if you see a simpler solution.

After sleeping on this, I realized we we actually do not need new ICs, because
for 'super' loads and stores the object is always the same - 'this'.
What we do need though is a flag on {Load,Store}[Keyed]IC that tells it is a
super call. The receiver would still be what comes from evaluation of 'super' (a
prototype of a home object), but super_call ICs will substitute 'this' instead
of the receiver if they need to do any calls. That is conceptually somewhat
simple, but requires massive plumbing. Here is a similar CL for own properties
(unfinished, not landed): https://codereview.chromium.org/458813002/

[Toon Verwaest, 2014-08-21 09:33:29]

@arv: I guess there were multiple bugs in your actual examples, one of which
being that the argument to .toMethod is actually the wrong prototype? If so,
understood ;)

@dslomov: no, that won't be sufficient. The receiver is always the same, but in
the IC we can't get to it. Plus, we'd have to change the entire IC mechanism
anyway. The base and receiver for any accessor call (or interceptor, ...?) are
just distinct objects. Our current LoadICs do not support this at all. It at
least means extending load ICs with one extra argument. As well as all handlers.
The dispatch has to happen on the base, but the result is applied to the
receiver.

The LookupIterator already does support this. If you pass in a receiver *and* a
"holder", the lookup starts at the holder, but the result is applied to the
receiver.

[Dmitry Lomov (no reviews), 2014-08-21 10:24:26]

On 2014/08/21 09:33:29, Toon Verwaest wrote:
> @arv: I guess there were multiple bugs in your actual examples, one of which
> being that the argument to .toMethod is actually the wrong prototype? If so,
> understood ;)
> 
> @dslomov: no, that won't be sufficient. The receiver is always the same, but
in
> the IC we can't get to it. Plus, we'd have to change the entire IC mechanism
> anyway. The base and receiver for any accessor call (or interceptor, ...?) are
> just distinct objects. Our current LoadICs do not support this at all. It at
> least means extending load ICs with one extra argument. As well as all
handlers.
> The dispatch has to happen on the base, but the result is applied to the
> receiver.

Yes, you are right: no cheating possible here. This calls for a proper design
doc. 

> 
> The LookupIterator already does support this. If you pass in a receiver *and*
a
> "holder", the lookup starts at the holder, but the result is applied to the
> receiver.

[Dmitry Lomov (no reviews), 2014-09-16 13:25:06]

Superseded by https://codereview.chromium.org/527963002/ and future work