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, are you sure that Windows and 32bit are OK with this change? I don’t understand why C linkage would affect things: Either the compiler puts structs in registers or it doesn’t. Geoff > On Jan 3, 2017, at 2:44 PM, Filip Pizlo <[email protected]> wrote: > > 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 <[email protected] > <mailto:[email protected]>> wrote: > >> 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 >> discover (in my reading of the code) that we don’t really need to use >> EncodedJSValue for most of our host functions (those of type NativeFunction, >> GetValueFunc, and PutValueFunc). >> >> I propose that we switch to using JSValue directly where we can. This has >> the benefit of: >> 1. better type safety with the use of JSValue (EncodedJSValue is a int64_t >> typedef). >> 2. more readable code (less marshaling back and forth with >> JSValue::encode()/decode()). >> >> The patch for this change can be found here: >> https://bugs.webkit.org/show_bug.cgi?id=166658 >> <https://bugs.webkit.org/show_bug.cgi?id=166658> >> >> Perf is neutral. Any opinions? >> >> Thanks. >> >> Mark >> _______________________________________________ >> webkit-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> <https://lists.webkit.org/mailman/listinfo/webkit-dev> > _______________________________________________ > webkit-dev mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
