Comment 4 for bug 1401316

Revision history for this message
Gary Fuehrer (gfuehrer) wrote :

Thanks for taking this on. As I wrote, it's been this way since I first started using GCC for ARM embedded, which was version 4.7.

My (very unknowledgeable) guess is that some front end optimizations are scrambling-up things too much for the backend peephole work, because I'm presuming that the inline assembly work-around hides things from most of these front end stages.

From what I've seen, the coding is already trying to do the "cleaver way", but doing it absurdly.

If the code is destined to use a constant pool (which I hope it always will, or at least have that as an option -- I love it so much!) then "addr[offset] = value" (and for structs, "addr->offset = value") would generally want to be coded as:

ldr r3, .L1 ;addr
mov r0, value ;or hopefully movs
str r0, [r3, offset] ;offset typically in range for, say, member of struct

L1: .word addr

If it's cleaver (as exhibited when using the inline assembly) the "r3" can be re-used or even adjusted with an "adds" for a subsequent addr. If the front end is combining the addr and the offset into a single "#imme1" then a valuable hint from the programmer is getting thrown away -- different member lookups within the same struct are ripe for direct translation.

I know that that's nothing like how compilers go about doing their work, but this is just FWIW.

-Gary