Re: [webkit-dev] Reducing the use of EncodedJSValue and use JSValue directly instead.

2017-01-03 Thread JF Bastien
On Tue, Jan 3, 2017 at 2:54 PM, Geoffrey Garen wrote: > EncodedJSValue was always just a work-around to convince the compiler to > put a JSValue in registers (instead of on the stack, with different > compilers disagreeing about where on the stack). > > I agree with removing

Re: [webkit-dev] Reducing the use of EncodedJSValue and use JSValue directly instead.

2017-01-03 Thread Geoffrey Garen
EncodedJSValue was always just a work-around to convince the compiler to put a JSValue in registers (instead of on the stack, with different compilers disagreeing about where on the stack). I agree with removing EncodedJSValue if possible. Did something change to make this possible? For

Re: [webkit-dev] Reducing the use of EncodedJSValue and use JSValue directly instead.

2017-01-03 Thread Darin Adler
> On Jan 3, 2017, at 2:33 PM, Mark Lam wrote: > > I propose that we switch to using JSValue directly where we can. Sounds like a great idea to me. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org

Re: [webkit-dev] Reducing the use of EncodedJSValue and use JSValue directly instead.

2017-01-03 Thread Filip Pizlo
I think that this is great! I agree with the policy that we should use JSValue everywhere that it would give us the same codegen/ABI (args in registers, return in registers, etc). -Filip > On Jan 3, 2017, at 14:33, Mark Lam wrote: > > Over the holiday period, I looked

[webkit-dev] Reducing the use of EncodedJSValue and use JSValue directly instead.

2017-01-03 Thread Mark Lam
Over the holiday period, I looked into the possibility of giving EncodedJSValue a default constructor (because I didn’t like having to return encodedJSValue() instead of { } in lots of places), and learned why we had EncodedJSValue in the first place (i.e. for C linkage). This led me to