- User Since
- Nov 24 2017, 7:16 AM (16 w, 5 d)
Fri, Mar 16
Thanks for that! OK, I'll update these reviews and nudge them forwards next week. I've just been very busy at work this week with a customer project, and nut been able to spend and time on wasm in the evenings at home.
Wed, Mar 14
I opened a can of worms! I think it can be cleaned up though...
Updated to not export by default, and creates export/import based on last-specified of --export-table and --import-table
Looks good, well caught
Tue, Mar 13
Since callback APIs are so common (eg high usage of dynCall in Emscripten applications) it would be nice if engines could optimise table-based access so that it's usable. Why standardise an API for doing an indirect call from JS, then tell users, "write a Wasm trampoline instead since that's faster than the browser-provided method".
- rebased and fixed conflicts
- Move Live flag from Symbol to UndefinedFunction::ImportLive to clarify what it is that we're marking live
- small nits based on feedback
Updated: removed chunk from MarkLive, fixed conflicts on rebase.
D44150 is blocked on this. There's not a huge benefit to moving the header into the LLVM repo, but it could enable code-sharing with WasmObjectWriter which would be nice.
Landing with just the name section changes (in Writer.cpp and Driver.cpp).
I'm hoping this one can be approved too, since it goes along with D44343. Any objections?
Mon, Mar 12
Updated: un-hid function used in test
Updated: addressed feedback, undid toString mangling changes
Updated to remove max/initial mem args, this just covers demangle now
Looks good, a few more lines of boilerplate in InputChunks.cpp are worth it for the added clarity.
Ping - has anyone who's worked on this code got a chance to look at it this week? Thanks very much!
Sat, Mar 10
How do you expect the linker to handle these custom sections? We currently discard them. Will there be semantics for how to merge them, if there are name clashes, etc...?
Cool, this is a good error-catching device. It could perhaps be debug-only on assert-only - but it's not exactly an expensive check, so I don't mind it being always on.
Hmm, does this work? I mean I can see that it generates an imported global of course, but it doesn't do anything. The code that actually references the import is still going to have 0 written in as the value of the relocation!
Thanks. We could consider sorting the type section (lexicographically by result/arg types) so at least we don't have to renumber all the type relocations through our test files when two functions swap order. Currently the types are ordered by functions that use them.
OK, I'll split this in two, and fix the nits regarding 0 for unset and forcing aligned values.
Thanks for the comments, I'll deal with those nits.
Fri, Mar 9
OK, sorry! Looks better.
Improve test a bit
I hope this is OK, but when I committed I made one additional change, that I think makes sense.