1156797 - consider exposing a "return value ignored" signal to c++ bindings

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Ben Kelly [:bkelly, not reviewing]]

One of the ways we could optimize our native promises is to avoid creating a Promise in .then() when the return value is ignored.  In order to do this, though, the Promise c++ could would need some way to know the return value does not matter.

Is it possible to expose a "return value ignored" signal to c++ bindings in some way?

If so, then each C++ binding could implement this optimization where it makes sense.

Comment 1

[Boris Zbarsky [:bzbarsky]]

In particular, what might work here is, in the situation where we could DCE the call based on its return value not being used but don't because it's effectful, to flag the MCall in some way... and then somehow make that state queryable from inside the call.

Comment 2

[Jan de Mooij [:jandem]]

We currently special-case array.splice calls with unused return value in Ion (see array_splice_impl's returnValueIsUsed argument); something like that could work.

Maybe LCallDOMNative can pass an extra word (with a "return value unused" bit) to the DOM method? Passing an extra argument is not free, but maybe there are other things we can put in there or maybe we can combine it with one of the existing arguments.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Hmm.  So array.splice uses BytecodeIsPopped(pc).  Does that mean we know statically, based on the pc, that the return value is unused, and don't have to rely on the JIT to do the analysis?

Past that, we could do the extra arg thing, yeah.  We'd make it opt-in on the part of the DOM method (as in, you'll need an IDL annotation to indicate you want the extra arg), so it won't slow down things that don't care about the optimization.  Combining with one of the existing args is pretty hard, sadly, though I'll think about it some more.

Comment 4

[Jan de Mooij [:jandem]]

(In reply to Not doing reviews right now from comment #3)
> Hmm.  So array.splice uses BytecodeIsPopped(pc).  Does that mean we know
> statically, based on the pc, that the return value is unused, and don't have
> to rely on the JIT to do the analysis?

Yup. Doing this elsewhere in the JIT might catch a few more cases, but it's probably also a bit more complicated.