expose math symbols on wasm32-unknown-unknown

[japaric]

r? @alexcrichton

I think this should do the trick. I wasn't sure how to write a test that checks that the symbols make it to a wasm file -- it seems that the wasm linker is lenient and doesn't throw errors when undefined symbols make it to the final artifact.

[japaric]

latest commit adds more math functions. Only four are missing from the list in rustwasm/team#84 (comment), but people are already working on them.

[japaric]

Once those four are in we'll also have all the functions required to put math support in core so we should think about the possible ways to do that.

(a) One way is to merge src/libstd/{f32,f64}.rs into src/libcore/num/{f32,f64}.rs (e.g. we move the current f32.sin implementation into core) and add all math symbols to compiler-bulitins. In that case the src/math.rs file in this repo should be available on all targets, and not just on wasm.

(b) The other way is to source import libm into core and implement the math methods by directly calling the libm functions, instead of using llvm intrinsics (e.g. intrinsics::sinf32). I don't know if there's any (optimization) advantage to using the llvm intrinsics, though.

The downside to (a) is that downstream users could run into linker errors ("undefined reference") if we forget to include some math symbol. (a) may also cause linker errors ("duplicate symbol") when linking statically, which is how the thumb targets do linking, if the user also links to e.g. glibc's libm.

The advantages to (b) are (i) llvm would be able to inline code (*) and remove unreachable branches in some cases producing smaller binaries, and (ii) it would be possible to turn the math methods into const functions in the future (we can't mark functions that call llvm intrinsics as const fn -- unless we use compiler magic, maybe).

(*) it might be possible to achieve inlining using approach (a) if we get link-time / cross-language LTO working.

I think doing either (a) or (b) would have the effect that all users would use our libm implementation of math functions (instead of e.g. glibc's libm implementation) and would close the possibility of providing your own implementation of math functions -- unless we do (a) and make the symbols weak.

So I would vote for approach (b) but we should implement it right after the next beta cutoff to maximize testing time.

[alexcrichton]

Hm I agree that the first strategy probably isn't workable, even for normal Linux distributions the linker command would look like:

cc .... crate.o ... -lm ... libcompiler_builtins.rlib

If crate.o references the sin symbol that'll instruct the linker to pull in libm.so to resolve the symbol. The symbol sin, though, is defined in some object in libcompiler_bulitins.rlib. That object may have some other symbols as well. If crate.o also references one of those other symbols in the compiler-builtins rlib then we'll get a duplicate symbol error for sin I believe.

Note that this strategy I think is workable if we compile each function in compiler-builtins into its own object file, which is indeed always a possibility!

For strategy (b) I'm a little hesitant to do that as well. I agree that it should solve the symbol visibility issue, but it has the downside of forcing users to use our own implementation which may not be as fast as the native implementations. Additionally I'm not sure if we want to commit long-term to making these const fns :)

Now all of this is somewhat moot if it's just for wasm specifically which has no other competing library here (other than shelling out to Math.sin and such). I'm curious on your thoughts on this though?

[japaric]

My main motivation for this is making (pure Rust) math support available to targets that don't have std support, like the thumb targets. I think that the Redox project might also be interested in pure Rust math support (cc @jackpot51); in their case they probably want the same as wasm (symbols in compiler-builtins) because I think they compile rust-lang/rust's libstd as it is.

In the case of the thumb targets they could mostly use the libm crate as it is (it contains extension traits that add methods like sin to f32 and f64) to get pure Rust math support. Except in the case of the modulo operation on floats; I believe in that case LLVM generates calls to the fmod / fmodf symbols and those would need to be provided by compiler-builtins or by some C implementation of libm (because of how linkers work). But that operation doesn't seem too common so it may not be an issue in practice.

In conclusion, I think that right now it may be best to provide only these math symbols for wasm and see how the use of the libm crate works out for the thumb targets. We can revisit putting math support in core after the edition release.

[alexcrichton]

Sounds reasonable to me! I think it'd also be fine to include this on thumb targets as well, but if it doesn't affect libcore other than fmod it may have limited utility :(

[japaric]

All the required functions by wasm are in now.

I think it'd also be fine to include this on thumb targets as well, but if it doesn't affect libcore other than fmod it may have limited utility

I think that might cause linker errors if the program is already being statically linked to libm but I can't check that right now / this week so I would hold off from doing that in this PR.

[alexcrichton]

Sounds reasonable to me! I think the wasm CI is still failing though?

[japaric]

https://travis-ci.org/rust-lang-nursery/compiler-builtins/jobs/405440231

wasm build is now fixed

[alexcrichton]

I pushed up another commit to use intrinsics! to ensure that these respect the mangled-names feature as well as have the C abi, but otherwise looks great!

Thanks so much for pushing on this @japaric, this is some amazing work!

[parasyte]

@japaric I would like to use this for my own custom target, too. Any thoughts on best approach? Right now I am using libm directly, and including a modified copy of math.rs for the intrinsics.

edit: Reached out to you on Discord, too.

[japaric]

@parasyte You mean you are compiling std for your custom target and are writing std applications? If that's your use case then we could provide the symbols behind a "math" Cargo feature.

If you are writing no_std applications then libm and its extension traits is the (stable) way to go.

[parasyte]

@japaric It's no_std for now, but I'm looking into what it will take to port the most important parts of std or your very own steed.

Thanks though, that answers my immediate question. 👍