Set relocation_model to Pic on emscripten target

[hoodmane]

So we can support dynamically linking libraries with Emscripten (otherwise we need to use nightly and -Zbuild-std to rebuild std with relocations).
@sbc100

[rust-highfive]

r? @lcnr

(rust-highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

⚠️Warning⚠️

• These commits modify compiler targets. (See the Target Tier Policy.)

[bors]

@hoodmane: 🔑 Insufficient privileges: Not in reviewers

[lcnr]

r? rust-lang/compiler

[hoodmane]

r? @petrochenkov

[petrochenkov]

wasm_base.rs has some comments relevant to this - https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/wasm_base.rs#L111-L118

 // This has no effect in LLVM 8 or prior, but in LLVM 9 and later when
// PIC code is implemented this has quite a drastic effect if it stays
// at the default, `pic`. In an effort to keep wasm binaries as minimal
// as possible we're defaulting to `static` for now, but the hope is
// that eventually we can ship a `pic`-compatible standard library which
// works with `static` as well (or works with some method of generating
// non-relative calls and such later on).

So considering

In older versions of emscripten PIC objects was not compatible with non-PIC binaries, but today it should be

it looks like that the tradeoffs from this change are more or less:

• Pros: Standard library can now be used for building dynamic libraries
• Cons: Produced binaries are larger and slower (how significantly?)
  • Some size and performance can be recovered by -Crelocation-model=static, but it won't affect code coming from the standard library.

[petrochenkov]

I guess the main alternative here is to build standard library specifically (libcore/libstd/etc) as PIC (in src/bootstrap) and keep the static default for everything else.

Then the tradeoffs will be:

• Pros: Standard library can now be used for building dynamic libraries
• Cons: Produced binaries are larger and slower (how significantly?), but only due standard library code
  • Size and performance can be recovered by using -Zbuild-std when really necessary.

[petrochenkov]

I have no idea what alternative is preferable here.
Maybe you have some basic benchmarks on binary size and runtime performance, just to understand the order of magnitude?
@rustbot author

[hoodmane]

Produced binaries are larger and slower

I think what @sbc100 said was that the final product should be about the same, but the object files will be larger and the compilation will be slower. This is a lot better than the final program being larger and slower.

[sbc100]

Produced binaries are larger and slower

I think what @sbc100 said was that the final product should be about the same, but the object files will be larger and the compilation will be slower. This is a lot better than the final program being larger and slower.

Indeed, to the best of my knowledge, all of the PIC overhead can be removing by wasm-opt when run it is run on the output of wasm-ld. That is the say, the output of the linker will still contain an overhead but binaryen can then eliminate all of it (IIUC).

[hoodmane]

I just built a library with PIC and with static. The PIC version is

2662027 bytes -- PIC
2661803 bytes -- static

so the static version come in 224 bytes smaller, which is a 0.008% difference. Kind of surprisingly similar size. Execution time is also the same within my large error margin. This isn't a very scientific test but I would believe that it makes no difference.

[sbc100]

I just built a library with PIC and with static. The PIC version is

2662027 bytes -- PIC
2661803 bytes -- static

so the static version come in 224 bytes smaller, which is a 0.008% difference. Kind of surprisingly similar size. Execution time is also the same within my large error margin. This isn't a very scientific test but I would believe that it makes no difference.

Thanks for running the numbers!

If you have time/interest would you mind running both of those binaries through wasm-opt -O2.. I would hope they would yield the same results, and, if not, we can look into why not... but regardless it seems like -fPIC has a negligible effect, which is great news.

[hoodmane]

After running wasm-opt -O2 on both, they differ by 204 bytes. wasm-opt reduces the pic file by 1887 bytes and the static file by 1867 bytes.

[petrochenkov]

Okay, seems fine to use pic by default then.
r=me after squashing commits.
@rustbot author

[hoodmane]

@rustbot label -S-waiting-on-author +S-waiting-on-review

[petrochenkov]

@bors r+ rollup

[bors]

📌 Commit ada2acc has been approved by petrochenkov