JF and I took a cursory look at this before, but I think it warrants a more
rigorous check before we commit to this change. I’ll do the due diligence.
> On Jan 3, 2017, at 2:54 PM, Geoffrey Garen wrote:
>
> EncodedJSValue was always just a work-around to convince the compiler to put
> a JSVal
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 if pos
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 example
> 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
https://lists.webkit.org/mailman/listinf
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 into the possibility of
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 discove
6 matches
Mail list logo
