No code generated for inline function call

[Andrew Neil]

There is no code generated for the led_rgb_toggle() call here:

led_rgb_toggle() is an inline function:

static inline void led_rgb_toggle( GPIO_PinState r_state, GPIO_PinState g_state, GPIO_PinState b_state )
{
#if defined PROJECT_WITH_RGB_LEDS
 if( r_state ) HAL_GPIO_TogglePin( LED_R_GPIO_Port, LED_R_Pin );
 if( g_state ) HAL_GPIO_TogglePin( LED_G_GPIO_Port, LED_G_Pin );
 if( b_state ) HAL_GPIO_TogglePin( LED_B_GPIO_Port, LED_B_Pin );
#endif
}

 

PROJECT_WITH_RGB_LEDS is defined in the Project defines (name has been changed for confidentiality):

 

It is working in other places.

Why would there be no code generated here?

 

This is CubeIDE v1.13.0 on Win 11

There are no build errors or warnings.

[Andrew Neil]

It was the Optimiser:

Turns out my definition of RGB_COLOUR_ALL was wrong, and actually equated to "none".

So the optimiser spotted that the call did nothing - and left it out!

As it should.

 

---

@Andrew Neil wrote:

It is working in other places..

---

Actually, it wasn't:

I had tried setting a breakpoint in led_rgb_toggle(), and it seemed that breakpoint was being hit.

What I hadn't noticed was that the place the breakpoint actually hit wasn't in led_rgb_toggle() - it was in another nearby inline function, with a similar name.

In fact, led_rgb_toggle() was not being used anywhere else in the Project.

So another misdirection by the Optimiser.

 

Optimisation level was -Og.

[waclawek.jan]

Sometimes one would wish the compiler/optimizer gives a warning about superficial/omitted code (it sometimes does about omitted variables).

But then, too many warnings lead users to ignore them/switch them off, so it's hard to strike a good compromise.

JW

[Andrew Neil]

Indeed.

 

But I do think the optimiser could communicate/cooperate better with the debugger - so the debugger (better) understands what the optimiser has done.

 

eg, not allowing you to set a breakpoint on code that doesn't exist - or, at least, warning when you do.

 

Especially when the place it does actually put the breakpoint is in an entirely different function.

 

Though, to be fair, I should have noticed that the breakpoint was actually happening in an entirely different function!

[waclawek.jan]

> could

Sure.

gcc/gdb are open source, you are free to contribute...  ;)

Some 50 years ago, Donald Knuth wrote an article, Structured Programming with go to Statements. It's obviously a (rather lengthy) essay inspired by the famous Dijkstra article with the even more famous Wirth title and as such not that much important; but it contains a very interesting and a slightly tangential chapter titled Program Manipulation Systems. In it, Knuth describes a hypothetical programming environment, which allows the programmer to see "online" the output of optimization and direct the optimizer interactively. He says there: As I say, this idea certainly isn't my own; it is so exciting I hope that  everyone soon becomes aware of its possibilities. We know what came of it.

The reason is, that writing a basic compiler or interpreter to a new language is relatively easy, whereas writing and *maintaining* an optimizer and its environment (i.e. a related debugger and a "language" to convey information between them, dwarf in case of gcc/gdb) is several orders of magnitude harder; so the enthusiastic youth still prefers to invent another new and shiny language (rust, cough cough) to the tiresome and usually publicly unacknowledged hard work.

JW