Arm cortex-m4 #[inline(never)] creates bigger firmware size?

embedded
1

I have this one shot timer function from Discovery book stm32f3 discovery:

#[inline(never)]
fn delay(tim6: &tim6::RegisterBlock, ms: u16) {
    // Set the timer to go off in `ms` ticks
    // 1 tick = 1 ms
    tim6.arr.write(|w| w.arr().bits(ms));
    // CEN: Enable the counter
    tim6.cr1.modify(|_, w| w.cen().set_bit());
    // Wait until the alarm goes off (until the update event occurs)
    while !tim6.sr.read().uif().bit_is_set() {}
    // Clear the update event flag
    tim6.sr.modify(|_, w| w.uif().clear_bit());
}

This function then gets called repeatedly and infinitely from the main loop.

When I check its size with GNU binutils size command. Release size:

text data bss dec hex filename
5916 0 4 5920 1720 target/thumbv7em-none-eabihf/release/clocks-and-timers

When I remove #[inline(never)], release size:

text data bss dec hex filename
5828 0 4 5832 16c8 target/thumbv7em-none-eabihf/release/clocks-and-timers

So it’s optimized slightly better without inline never?

1 Like
2

Is that really surprising? Calling a function implies always pushing parameters and return address on the stack (or into registers), jumping to the address of the function, and finally jumping back. It might be also required to save and restore register content. So I am not surprised that for a function with a tiny body, inlining can result in shorter code.

1 Like
3

Thanks for the input. What I’m curious about is that when targeting for smallest possible size, how can I know inlining strategy via compiler attribute helps or hinders? Trail and error or there are tools for this? Thanks.

4

In the general case, there is no better way to know than “try all the possibilities”. Inlining duplicates code, but it can also allow greatly simplifying the duplicate.

If a function is called by only one call site (as I think you are saying is the case in your program), inlining it will be smaller, all else being equal — but making the calling function bigger by inlining into it might change other choices of the optimizer.

Just keep experimenting. And look at the assembly to learn what those code bytes are actually doing, so you have a better idea of when inlining will help.

5 Likes
5

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.