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
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
> 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
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
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
5 matches
Mail list logo