Use clang -fwhole-program-vtables when possible

[kripken]

Emscripten is aware at compile time whether an object file will be used
in a dynamic linking context, so we are within our rights to apply that
flag in those situations, when doing LTO.

Hopefully this does not run into any LLVM LTO bugs...

This reduces 35% of call_indirect instructions in the Bullet benchmark
(making them direct calls, some of whom end up inlined), so it may be
very useful in principle.

I added a new test here, in the first commit which is before the
optimization. The second commit shows the effect on that test: just a
few bytes of size difference, so on simple C++ programs without large
vtable hierarchies this is not expected to help much I suppose.

[sbc100]

How about inverting this condition and the name of this variable.

e.g.

dylink_supported = settings.RELOCATABLE or settings.LINKABLE or '-fPIC' in user_args

Then I believe the '-fwhole-program-vtables' should be added only when this is not true... so it would not be in the same block as `-fvisibility=default' (which is for relocatable output).

[kripken]

Unfortunately this fails many tests in LTO and ThinLTO, e.g. thinltoz.test_EXPORT_EXCEPTION_HANDLING_HELPERS crashes in wasm-ld:

wasm-ld: /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/llvm/lib/MC/WasmObjectWriter.cpp:1814: uint64_t (anonymous namespace)::WasmObjectWriter::writeOneObject(MCAssembler &, const MCAsmLayout &, DwoMode): Assertion `DataLocations.count(&WS) > 0' failed.                                                                                                                    

At least it is an error in the wasm backend and not generic code.

@sbc100 any idea? Or if not, who knows WasmObjectWriter best?

[sbc100]

Unfortunately this fails many tests in LTO and ThinLTO, e.g. thinltoz.test_EXPORT_EXCEPTION_HANDLING_HELPERS crashes in wasm-ld:

wasm-ld: /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/llvm/lib/MC/WasmObjectWriter.cpp:1814: uint64_t (anonymous namespace)::WasmObjectWriter::writeOneObject(MCAssembler &, const MCAsmLayout &, DwoMode): Assertion `DataLocations.count(&WS) > 0' failed.                                                                                                                    

At least it is an error in the wasm backend and not generic code.

@sbc100 any idea? Or if not, who knows WasmObjectWriter best?

Thats probably me yes. This looks like a basic assumption of the writer if failing, but I can't imagine why. I'll try to take a look soon.