Fix for code size regression in log/log2/pow due to recent musl upgrade

[sbc100]

Restore the older versions of these files and used them in place of the
new ones when optimizing for size.

These regressions were intended and deemed acceptable in upstream
musl:
emscripten-core/musl@e4dd653
emscripten-core/musl@2a3210c
emscripten-core/musl@236cd05

Fixes: #15483

[sbc100]

Without the system_libs.py change the new test fails with:

size of a.html == 673, expected 673, delta=0
size of a.html.gz == 431, expected 431, delta=0
size of a.js == 137, expected 137, delta=0
size of a.js.gz == 141, expected 141, delta=0
size of a.wasm == 8012, expected 2731, delta=5281 (+193.37%)
size of a.wasm.gz == 5789, expected 1620, delta=4169 (+257.35%)
Total output size=8822 bytes, expected total size=3541, delta=5281 (+149.14%)
Total output size gzipped=6361 bytes, expected total size gzipped=2192, delta=4169 (+190.19%)
Oops, overall generated code size regressed by 5281 bytes!
FAIL

======================================================================
FAIL: test_minimal_runtime_code_size_math (test_other.other)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/google/home/sbc/dev/wasm/emscripten/tests/common.py", line 303, in resulting_test
    return func(self, *args)
  File "/usr/local/google/home/sbc/dev/wasm/emscripten/tests/test_other.py", line 9021, in test_minimal_runtime_code_size
    self.assertEqual(total_output_size, total_expected_size)
AssertionError: 8822 != 3541

[kripken]

I'm having trouble understanding the meaning of all here. Perhaps a comment would help? Even reading the code below I'm not sure why it is needed, it seems like is_optz should be a variation on the library basically.

Speaking of variations, we do have OptimizedAggressivelyForSizeLibrary which this could use? That would automatically provide the C define. That could then be used in the main .c file to do an ifdef on that and include the _small version etc. - would that be simpler?

[sbc100]

Yes, this is using the OptimizedAggressivelyForSizeLibrary method. Indeed the only library we currently compile in the mode is libc-rt and its the self.is_optz on this library that signals if we are in this mode.

This is a freestanding function that the libc-rt library then calls and passes along the paramater.

[sbc100]

The reason this is a freestanding function is that it is used in two different places. In libc-rt its used to select which math functions to compile, and int libc its used to select which math files to ignore.

[sbc100]

I added a comment which I hope will make this more clear. I also renamed the all argument to superset.

[sbc100]

In this case it seems much easier to have two separate files than to use the #ifdef mechanism (which would involve modifying upstream code).

[kripken]

Thanks, now I see! Good comment.

Yes, I agree this approach is best.

[haberbyte]

Nice, thank you @sbc100

I am interested in benchmarking this. What would be a good way to do that?
I thought maybe generating a bunch of random numbers first, then calling the functions.

Performance probably differs across environments, right? (node, browser, ...)

[sbc100]

I would expect performance to vary by architecture and by engine, but the same engine running in the browser and outside the browser should the be same (e.g. it should be enough to measure on d8/node rather than launching chrome).