Suboptimal compiler behavior for Cortex M0 (?)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by gbm on Wed May 11 04:06:10 MST 2011
Code-Red support - please read and check.

While playing with my NanoBlinker I tried to generate versions for LPC11xx and LPC13xx. I changed the setting of target MCU from LPC13xx to LPC11xx without changing the code, just to check the suspected compiler behavior. The result was:
In Cortex M0 mode, the compiler does not remove the unneeded
push {lr} instruction from the prologue of neverending routine, which makes the routine longer than in M3 mode. Other differences exist in the code but this one is critical.
The code was generated with -O3 and -Os settings.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by gbm on Wed May 11 22:30:13 MST 2011
The main advantage of Cortex M family for C programming is that ISRs do NOT require any special handling from the compiler!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by atomicdog on Wed May 11 20:01:53 MST 2011

Quote: larryvc
Hi John,

Who were you replying to?

I just posted above to let CodeRedSupport know of the push in the ResetISR on the 1769. I tried your suggestion above on the ResetISR definition and it made no difference, the push still occurred.

Sorry to jump in on your thread gbm, I thought it important enough to flag this as a compiler anomaly as well.

Larry

Hi Larry,
I was responding to the OP. Actually, I wouldn't expect that attribute to work on an ISR since the function requires special handling by the compiler.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Wed May 11 17:55:37 MST 2011

Quote: atomicdog
Have you tried playing with function attributes like noreturn to see if that makes a difference?

 __attribute__ ((noreturn));

Hi John,

Who were you replying to?

I just posted above to let CodeRedSupport know of the push in the ResetISR on the 1769. I tried your suggestion above on the ResetISR definition and it made no difference, the push still occurred.

Sorry to jump in on your thread gbm, I thought it important enough to flag this as a compiler anomaly as well.

Larry

lpcware · ‎06-15-2016

Content originally posted in LPCWare by gbm on Wed May 11 09:20:37 MST 2011
The spurious push {lr} is removed (optimized) when the code is compiled for LPC17xx or 13xx (Cortex M3). It is not removed if the target is set to LPC11xx (with all other options set identically as for M3) - this is strange and inconsistent behavior of the compiler. Certainly, the code is correct in both cases.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by atomicdog on Wed May 11 09:17:42 MST 2011
Have you tried playing with function attributes like noreturn to see if that makes a difference?

 __attribute__ ((noreturn));

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Wed May 11 08:57:09 MST 2011

Quote: CodeRedSupport
OK, we can see that if you have a function containing an infinite loop like this one that never returns, the compiler is failing to optimise out the stack operation at the start.

We will flag this up the system. However I would certainly not categorise this as a critical bug - the code produced certain still appears to be syntatically correct. The only thing it breaks is your attempt to squeeze your minimal blinky application into the vector table :rolleyes:

Regards,
CodeRedSupport

Hi CodeRedSupport,

See this post:

http://knowledgebase.nxp.com/showpost.php?p=8141&postcount=49

This also shows the compiler not optimizing out the stack push and this was in a much more normal program. I have also duplicated this in another very normal imported example project. I can't find it right now but when I do I will post it. It is a Cortex M3 (LPC1769) and not an M0, as this thread is about, but the compiler does demonstrate inconsistent behaviour nonetheless.

It may not be a critical bug, it certainly is a [B]unique feature[/B].:eek:

You have to admit that gbm's squeeze is brilliant.:)

Larry

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed May 11 08:17:27 MST 2011

Quote: gbm

In Cortex M0 mode, the compiler does not remove the unneeded
push {lr} instruction from the prologue of neverending routine, which makes the routine longer than in M3 mode. Other differences exist in the code but this one is critical..

OK, we can see that if you have a function containing an infinite loop like this one that never returns, the compiler is failing to optimise out the stack operation at the start.

We will flag this up the system. However I would certainly not categorise this as a critical bug - the code produced certain still appears to be syntatically correct. The only thing it breaks is your attempt to squeeze your minimal blinky application into the vector table :rolleyes:

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed May 11 07:17:32 MST 2011
I'm sorry but I do not understand your question. You are going to have to post some code to explain what you mean.