Linker not garbage collecting correctly

[smgoldade]

When soft-float support was added, CRT LTO was removed with this commit to prevent bloat.

However, the linker does not appear to be properly removing unused library code for an unknown reason. For the same codebase that utilizes some divide and shift operations, on SDK release v8.0.1 using LTO leaves behind only the following methods comprising a total size of 577 bytes.

 ed45     ed45        a     1         lto.tmp:(.text.__ashlqi3)
    ed45     ed45        a     1                 __ashlqi3
    ed4f     ed4f       13     1         lto.tmp:(.text.__ashlhi3)
    ed4f     ed4f       13     1                 __ashlhi3
    ed62     ed62        a     1         lto.tmp:(.text.__lshrqi3)
    ed62     ed62        a     1                 __lshrqi3
    ed6c     ed6c       34     1         lto.tmp:(.text.__mulhi3)
    ed6c     ed6c       34     1                 __mulhi3
    eda0     eda0       c9     1         lto.tmp:(.text.__udivhi3)
    eda0     eda0       c9     1                 __udivhi3
    ee69     ee69       a8     1         lto.tmp:(.text.__umodhi3)
    ee69     ee69       a8     1                 __umodhi3
    ef11     ef11       75     1         lto.tmp:(.text.__divhi3)
    ef11     ef11       75     1                 __divhi3

By changing to release v8.1.0, the following methods are included in the text section, most of them unused, inflating the size to 6729 bytes:

    a72c     a72c     16f1     1         /home/smgoldade/llvm-mos/bin/../mos-platform/common/lib/libcrt.a(divmod.cc.obj):(.text)
    a72c     a72c       5d     1                 __udivqi3
    a789     a789       f3     1                 __udivhi3
    a87c     a87c      1cc     1                 __udivsi3
    aa48     aa48      3f3     1                 __udivdi3
    ae3b     ae3b       40     1                 __umodqi3
    ae7b     ae7b       a8     1                 __umodhi3
    af23     af23      14f     1                 __umodsi3
    b072     b072      380     1                 __umoddi3
    b3f2     b3f2       71     1                 __udivmodqi4
    b463     b463      142     1                 __udivmodhi4
    b5a5     b5a5       7b     1                 __divqi3
    b620     b620       89     1                 __divhi3
    b6a9     b6a9       d4     1                 __divsi3
    b77d     b77d      164     1                 __divdi3
    b8e1     b8e1       49     1                 __modqi3
    b92a     b92a       7d     1                 __modhi3
    b9a7     b9a7       c2     1                 __modsi3
    ba69     ba69      13d     1                 __moddi3
    bba6     bba6       f1     1                 __divmodqi4
    bc97     bc97      186     1                 __divmodhi4
    be1d     be1d      245     1         /home/smgoldade/llvm-mos/bin/../mos-platform/common/lib/libcrt.a(mul.cc.obj):(.text)
    be1d     be1d       1b     1                 __mulqi3
    be38     be38       34     1                 __mulhi3
    be6c     be6c       97     1                 __mulsi3
    bf03     bf03      15f     1                 __muldi3
    c062     c062      113     1         /home/smgoldade/llvm-mos/bin/../mos-platform/common/lib/libcrt.a(shift.cc.obj):(.text)
    c062     c062        a     1                 __ashlqi3
    c06c     c06c       13     1                 __ashlhi3
    c07f     c07f       17     1                 __ashlsi3
    c096     c096       1f     1                 __ashldi3
    c0b5     c0b5        a     1                 __lshrqi3
    c0bf     c0bf       13     1                 __lshrhi3
    c0d2     c0d2       17     1                 __lshrsi3
    c0e9     c0e9       1f     1                 __lshrdi3
    c108     c108        c     1                 __ashrqi3
    c114     c114       17     1                 __ashrhi3
    c12b     c12b       21     1                 __ashrsi3
    c14c     c14c       29     1                 __ashrdi3

If you need a codebase for comparison, the example came from compiling a pre-release of an NES game I have been creating located at my neschess repository. As this currently targets the NROM cartridge, v8.0.1 generated a binary close to maximum size, but with the additional size of v8.1, the binary ROM size is exceeded.