Programm size leaps

[burrbull]

2018-01-26
Mint 18.3
rustc 1.25.0-nightly (5965b7901 2018-01-19)

example	size
blinky	2396
delay	2460
hello	10584
led	804
motor	14222
mpu9250	16150
pwm	12196
qei	12960
reactive-blinky	2160
reactive-serial-circ	12362
serial-dma-circ	12290
serial-dma-rx	2548
serial-dma-tx	2700
serial	12442

In serial example one string:
let received = block!(rx.read()).unwrap();
adds +9614 bytes

[therealprof]

Can you run xargo bloat on that one?

[japaric]

This is ThinLTO doing a poor job optimizing the program. Compiling reactive-serial-circ with -Z thinlto=no reduces the size from 12154 to 890. All the bloat is the formatting machinery. I'll send a PR disabling ThinLTO here and in the f3 crate.

[therealprof]

  File  .text   Size Name
  0.5%  19.7% 1.4KiB core::fmt::Formatter::pad_integral
  0.3%  13.4%   962B core::fmt::Formatter::pad
  0.2%  10.0%   720B stm32f103xx_hal::rcc::CFGR::freeze
  0.2%   9.4%   672B core::str::slice_error_fail
  0.2%   7.6%   544B core::fmt::write
  0.2%   7.5%   538B <char as core::fmt::Debug>::fmt
  0.1%   5.8%   414B _ZN6serial4main17h1be84e364a35f49dE.llvm.5ED7C697
  0.1%   3.7%   266B _ZN4core3fmt10ArgumentV110show_usize17hfc241669cfd70b9cE.llvm.9F0C0883
  0.1%   3.7%   266B core::fmt::num::<impl core::fmt::Display for usize>::fmt
  0.1%   3.7%   266B core::fmt::num::<impl core::fmt::Debug for usize>::fmt
  0.1%   2.5%   182B _ZN4core12char_private5check17hbe4ec24cd175581eE.llvm.C2A66DC6
  0.0%   1.8%   132B [14 Others]
  0.0%   1.8%   128B <&'a T as core::fmt::Debug>::fmt
  0.0%   1.6%   112B cortex_m_rt::reset_handler
  0.0%   1.5%   106B <stm32f103xx_hal::serial::Error as core::fmt::Debug>::fmt
  0.0%   1.3%    92B core::result::unwrap_failed
  0.0%   1.1%    78B core::slice::slice_index_order_fail
  0.0%   1.1%    78B core::slice::slice_index_len_fail
  0.0%   1.0%    74B core::panicking::panic_bounds_check
  0.0%   1.0%    70B <core::ops::range::Range<Idx> as core::fmt::Debug>::fmt
  0.0%   0.8%    60B core::panicking::panic

The worst offender is the usual formatting stuff.

[therealprof]

@japaric Not even sure how to control ThinLTO, whether I explicitly enable or disable it, I'll always get:

  = note: /usr/local/Cellar/gcc-arm-none-eabi-63/20170223/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/crt0.o: In function `_start':
          (.text+0xe0): undefined reference to `__libc_init_array'
          /usr/local/Cellar/gcc-arm-none-eabi-63/20170223/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/crt0.o: In function `_start':
          (.text+0xf0): undefined reference to `exit'
          collect2: error: ld returned 1 exit status

[japaric]

@therealprof

$ cat .cargo/config
[target.thumbv7m-none-eabi]
runner = 'arm-none-eabi-gdb'
rustflags = [
  "-C", "link-arg=-Tlink.x",
  "-C", "linker=arm-none-eabi-ld",
  "-Z", "linker-flavor=ld",
  "-Z", "thinlto=no", # <-
]

[build]
target = "thumbv7m-none-eabi"

[therealprof]

@burrbull is correct, the read() somehow drags in the whole formatting crap.

[therealprof]

😲

With thin_lto=no:

  0.2%  57.1% 306B main
  0.1%  19.0% 102B cortex_m_rt::reset_handler
  0.0%   1.9%  10B core::result::unwrap_failed
  0.0%   1.9%  10B core::panicking::panic
  0.0%   1.9%  10B SVCALL
  0.0%   1.9%  10B MEM_MANAGE
  0.0%   1.9%  10B DEBUG_MONITOR
  0.0%   1.9%  10B PENDSV
  0.0%   1.9%  10B USAGE_FAULT
  0.0%   1.9%  10B SYS_TICK
  0.0%   1.9%  10B NMI
  0.0%   1.9%  10B DEFAULT_HANDLER
  0.0%   1.9%  10B BUS_FAULT
  0.0%   1.9%  10B HARD_FAULT
  0.0%   0.7%   4B core::panicking::panic_fmt
  0.0%   0.7%   4B cortex_m_rt::default_handler
  0.0%   0.0%   0B [0 Others]

[therealprof]

@japaric opt-level="s" with and without ThinLTO creates smaller binaries, so you might want to add that to Cargo.toml, however it still inserts the formatting crap although this shows a bit clearer where it might be coming from:

  0.2%  11.8%   744B stm32f103xx_hal::rcc::CFGR::freeze
  0.2%  11.6%   730B core::fmt::Formatter::pad
  0.2%  10.5%   666B core::str::slice_error_fail
  0.2%  10.0%   630B [24 Others]
  0.2%   9.3%   586B core::fmt::Formatter::pad_integral
  0.1%   6.0%   380B _ZN6serial4main17h2867085352665504E.llvm.40D5859B
  0.1%   6.0%   376B core::fmt::write
  0.1%   4.1%   258B core::fmt::num::<impl core::fmt::Display for usize>::fmt
  0.1%   3.9%   248B core::char_private::is_printable
  0.1%   3.4%   214B core::fmt::Formatter::pad_integral::{{closure}}
  0.1%   3.3%   208B <&'a mut I as core::iter::iterator::Iterator>::next
  0.1%   2.9%   182B _ZN4core12char_private5check17hcb4b56b2e9304072E.llvm.8BF3156B
  0.1%   2.6%   164B <char as core::fmt::Debug>::fmt
  0.0%   2.2%   136B <stm32f103xx_hal::serial::Error as core::fmt::Debug>::fmt
  0.0%   2.0%   126B core::fmt::Formatter::getcount
  0.0%   2.0%   126B core::fmt::num::<impl core::fmt::Display for u8>::fmt
  0.0%   1.9%   122B core::fmt::builders::DebugTuple::finish
  0.0%   1.9%   118B <stm32f103xx_hal::serial::Serial<stm32f103xx::USART3, PINS>>::usart3
  0.0%   1.8%   112B cortex_m_rt::reset_handler
  0.0%   1.6%   100B <core::char::EscapeUnicode as core::iter::iterator::Iterator>::next
  0.0%   1.5%    92B core::result::unwrap_failed

Looks as if there're a potential panic somewhere which rustc cannot determine will not happen with ThinLTO enabled.

[japaric]

Workaround landed in #45. The root of the problem (ThinLTO) has to be fixed upstream.