MikeInnes
ccall / libjulia functions
Where in the pipeline would one swap out libjulia functions for the wasm/js equivalent?
Is that just adding to the wasmfuncs dict?
That dict doesn't have the argument types, so it seems like something different might be needed to swap out functions that have multiple (dispatch) methods.
As in, jl_ ccalls in the IR? I've basically only come across intrinsics so far so that's what wasmfuncs is targeted at. wasmcall is slightly more primitive than wasmfunc so you can do more with that, or in the worst case you can just add a branch here with some arbitrary transformation.
Yes, that's for when you hit ccalls and in a few cases llvmcalls, but we might want to intercept some calls earlier in the calling sequence. You hit this for a lot of things like Arrays. Swapping out some things like error checking also helps get code to work in some cases.
Also, great stuff! I like your overall plan. Many of the approaches I've tried run into roadblocks that required me to push to lower and lower levels of processing code_typed code anyway, so I'm all for trying this. This seems like a good approach for generating small wasm. If you have a to-do list that you need help with, I'd be happy to pitch in.
That's a bit harder. Usually these functions get inlined, at which point it's not very easy to intercept them (we've hit this a lot with CUDAnative as well). I think at some point the compiler is going to have to provide some kind of api for replacing functions wholesale. Until then, just replacing e.g. throw with a trap should get us by.
Glad you like it! I've opened issues here and on WebAssembly.jl for all the immediate things I can think of. Any suggestions on top of that are more than welcome – if you play around with it you'll no doubt run into things that could be improved.
Calling JavaScript functions may be another use of ccall. Or, maybe we need jscall.