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 <gga...@apple.com> 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 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 <fpi...@apple.com >> <mailto:fpi...@apple.com>> 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 <mark....@apple.com >> <mailto:mark....@apple.com>> 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 >>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
