On Tue, 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? > Recent MSVC seems happy, 32- and 64-bit: https://godbolt.org/g/XVaDyz Unless you had another example in mind? 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> 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> 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 > > Perf is neutral. Any opinions? > > Thanks. > > Mark > > _______________________________________________ > webkit-dev mailing list > 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 > > > > _______________________________________________ > webkit-dev mailing list > 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
