GP32 Code Sourcery G++ Assembly Code Quality

[maciek_urbanski]

In my analysis of SGX architecture I'm working primarily with ARM assembly. This is my first contact with ARM architecture, so I learn it on-the-fly, but I'm loving every minute of it. It's instruction set is a pure elegance.

The only fly in the ointment is quality of code produced by Code Sourcery G++.

I found some fairy obvious sub-optimialities, most involving ARM predicated execution or (lack of) variable limit analysis.

example 1:
CODE

1: CMP R0, #constant
2: LDRNE R3, [R1,#4]
3: MOVNE R3, R3,LSR#20
4: ANDNE R0, R3, #1
5: LDREQ R3, [R1,#4]
6: MOVEQ R3, R3,LSR#23
7: ANDEQ R0, R3, #1


Loading [R1,#4] to R3 occurs in not-equal and in equal case. The same goes for boolean 'and'.
Optimized version would look like this:
CODE

1: CMP R0, #constant
2: LDR R3, [R1,#4]
3: MOVNE R3, R3,LSR#20
6: MOVEQ R3, R3,LSR#23
7: AND R0, R3, #1


Seems GCC is handling ARM conditional instructions rather poorly (from performance standpoint).



example 2:
CODE

1: BL some_function_returning_bool_in_R0
2: CMP R0, #0
3: ADDEQ R0, R0, #1
4: LDRNE R3, [R4]
5: MOVNE R0, #1
6: ORRNE R3, R3, #0x80
7: STRNE R3, [R4]


Line 5 is not necessary. after 1. R0 can be either 0 or 1. After 3 it can be only 1.
Optimized version would look like this:
CODE

1: BL some_function_returning_bool_in_R0
2: CMP R0, #0
3: ADDEQ R0, R0, #1
4: LDRNE R3, [R4]
6: ORRNE R3, R3, #0x80
7: STRNE R3, [R4]



There's a lot of code like this produced by Code Sourcery G++ (those are not by any means isolated occurrences).

Boy, I wonder how fast it will be when Code Sourcery will fix those pesky little flaws. B)

Damn, I made mistake in subtopic. :angry:

MOD: please change subtopic to '...is not very high...'

 

[Klepto]

I noticed similar stuff when I was learning ARM assembly and reading disassembled c code produced with gcc. I was compiling without optimisation but was surprised to see a few instruction sequences that actually did nothing.

 

[Exophase]

No one ever really believes me when I say that GCC produces pretty bad ARM (there are a lot of other issues too)

Just goes to show that it's naive to believe that a compiler will virtually always beat even an expert assembly writer, and yet a lot of highly experienced programmers believe this anyway.

 

[pelrun]

And here I was thinking that conventional wisdom was optimised compiler output could sometimes be nearly as good as that written by an experienced assembly programmer, not the other way around...

 

[Capn_Fish]

What kind of performance hit are we talking about here? 1%? 10%?

 

[maciek_urbanski]

What kind of performance hit are we talking about here? 1%? 10%?

It really depends on the algorithm used. If the sub-optimal code would reside in tight loop run very often (think video filters) impact would be significant ("guesstimating" 30% in really bad cases).
In case of general purpose code, like the one I'm working on currently - it's negligible ("guesstimating" <1%).
But it still looks awful. B)

 

[Capn_Fish]

What kind of performance hit are we talking about here? 1%? 10%?

It really depends on the algorithm used. If the sub-optimal code would reside in tight loop run very often (think video filters) impact would be significant ("guesstimating" 30% in really bad cases).
In case of general purpose code, like the one I'm working on currently - it's negligible ("guesstimating" <1%).
But it still looks awful. B)

That's fairly frightening.

Thanks.

 

[Exophase]

It's pretty regular for me to improve performance of tight loops by 50-100% over GCC, although they could have improved since then perhaps (last tested on whatever GCC 4 Open2x has been on). Afterall, CodeSorcery was hired specifically to improve ARM support in GCC. But it seems like they haven't been doing the world's best job.