GNU Arm Embedded Toolchain

Trying to reason about emitted loop code

Asked by Michael Steinberg

Hello, I'm currently having a hard time trying to explain following emitted code:

[ASM]
  39 0002 094D ldr r5, .L6
  40 .L2:
  47 .loc 2 410 0 discriminator 1
  48 0004 2B69 ldr r3, [r5, #16]
  49 0006 084C ldr r4, .L6
  50 .LBE2375:
  51 .LBE2374:
  52 .LBE2373:
  53 .LBE2372:
  75:../source/stm/eth.cpp **** while(device.macmiiar.field<macmiiar::mb>());
  54 .loc 1 75 0 discriminator 1
  55 0008 DB07 lsls r3, r3, #31
  56 000a FBD4 bmi .L2
  ...
 108 .L6:
 109 0028 00000000 .word __eth__device_0x40028000
[/ASM]

Can you explain what that load to r4 is for? I tried to reason about loop alignment or something along the lines, but is a pc-relative memory load not a bit intrusive for that?
Note I'm not saying I'm convinced it is bad code or something, I just don't understand it...
This code was emitted from 4.9q4 compiler, but 4.8q3 does the same thing.

Kind regards

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Michael Steinberg
Solved:
Last query:
Last reply:
Revision history for this message
Joey Ye (jinyun-ye) said : 		#1

Without source code it is hardly explainable...

Revision history for this message
Michael Steinberg (decimad) said : 		#2

Of course you are right. I iteratively stripped down the source code to following minimal sample:

[cpp]

namespace minimal {

 volatile unsigned int some;

 void sample_function() {
  while(some);
  some = 5;
 }

}

[/cpp]

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said : 		#3

Hi Michael,

There is indeed a bug. One of the load correspond to the while loop while the other correspond to the store (and is moved earlier in the code). I'll create an internal ticket for us to follow it up but feel free to create one as well on launchpad so that you will be notified of progress.

Best regards,

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said : 		#4

Hi Michael,

For your information we've been working on several patches to fix this problem at different level in GCC. The feedback from the community was quite positive so whenever general development of GCC starts again (we are in a stabilization phase to prepare a new release) they should get all in. You can follow the current state of the discussion at [1] and [2].

[1] https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01048.html
[2] https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00820.html

Best regards.

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said : 		#5

Hi Michael,

Just to let you know, a patch has already been accepted [1] for next version of GCC (GCC 6) that should fix this problem. It seems similar problem [2] had been noticed already.

[1] https://gcc.gnu.org/ml/gcc-cvs/2015-04/msg00596.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34503

Revision history for this message
Michael Steinberg (decimad) said : 		#6

Hi Thomas,

A year has passed, but I can't conclude without a Thank You for keeping me updated so nicely! Crossing my fingers for GCC6 already ;)

Best regards,
Michael