Sam Clegg

> @alexcrichton > > > If I might throw out another possible alternative, could it perhaps also be possible to write this down in source itself? > > For example...

> > I believe the libcall function such as `__multi3` are not designed to be directly callable from C code. They only need to be callable from the llvm backend,...

> I was assuming that in a world with universal support for multi-value (effectively the state of the world now, but I recognize that this is a separate, larger discussion)...

> because on native targets, this will be inlined Can you explain what you mean here? Have you seen native platform target that provide bitcode/LTO-able versions of compiler-rt? As far...

> @sbc100 > > > True, once multi-value is universally available we could just assume it when we build compiler-rt. > > In emscripten we will want to continue to...

@sunfishcode

Yes I agree that its a shame the `--export-dynamic` does anything today with wasi-sdk. Without that flag I guess we could defer the decision about `visibility=default` since visibility would mean...

Yes, IIUC in emscripten the decision thus far has been to go with compatibility with ELF by default. There exist options to narrow down the shared library exports, but by...

> I'm ok with such changes if they are useful for now. But I do think figuring out a shared story would be the right long-term plan, when the time...

I don't think https://reviews.llvm.org/D113435 increases the divergence, I'm just trying to clarify/document the current divergence. Having the defaults for `wasm32-unknown-emscripten` encoded is llvm rather than constantly overriding them in the...