Products > Programming
Efficient C Code for ARM Devices
hamster_nz:
Dropping this here as it looks to be interesting to many:
https://m.eet.com/media/1157397/atc-152paper_shore_v4.pdf
Has anybody seen "__promise" before? I haven't! - gives compiler hints to allow better code generation.
Example from paper:
--- Code: ---void f(int *x, int n)
{
int i;
__promise((n > 0) && ((n&7)==0));
for (i = 0; i < n; i++) {
x[i]++;
}
}
--- End code ---
SiliconWizard:
--- Quote from: hamster_nz on October 02, 2019, 08:56:50 pm ---Has anybody seen "__promise" before? I haven't! - gives compiler hints to allow better code generation.
--- End quote ---
Ahah, nope.
"restrict", yes. It's actually C99, and doesn't need any underscore for any C99-compliant compiler. "restrict" can yield some interesting optimizations when used properly.
But "__promise"? Ahem. It just looks like some kind of "contract", but used completely backwards. Instead of making sure some condition will always hold true, it makes the compiler assume it is, without any guarantee that it's ever going to actually hold true. Sure it can lead to interesting opportunities for optimizations, but it's rather totally atrocious from any other point of view... ::)
Just pass to "n" any value that breaks the "promise", and the generated code may not only not be optimized, but could as well be completely wrong for this value. EEK. Talk about a good idea...
And now if you actually actively CHECK for a condition, the compiler will not only generate code to check it's true, but will also have all hints it needs to optimize the code when it is. Much, much better (sure you get the check overhead, but you can't have it all. Oh, and there's now the interesting static_assert() in C11...)
Just my opinion. Favoring optimization at the obvious (unless I missed something) expense of security is... not always judicious, to put it gently. ;D
Finally, I'm not quite sure which compiler supports this. Apparently armcc: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491g/CJACHIDG.html
which I'll probably never get to use anyway. Oh well.
hamster_nz:
--- Quote from: SiliconWizard on October 02, 2019, 10:26:58 pm ---Sure it can lead to interesting opportunities for optimizations, but it's rather totally atrocious from any other point of view... ::)
--- End quote ---
Exactly
Promises are made
Code known to be broken
Programmers cry
andersm:
It looks like you can convince GCC to perform the same optimization like so:
--- Code: ---void f(int *x, int n)
{
int i;
if ((n > 0) && ((n&7)==0)) {
for (i = 0; i < n; i++) {
x[i]++;
}
}
else {
__builtin_unreachable();
}
}
00000000 <f>:
0: 3804 subs r0, #4
2: eb00 0181 add.w r1, r0, r1, lsl #2
6: f850 3f04 ldr.w r3, [r0, #4]!
a: 3301 adds r3, #1
c: 4281 cmp r1, r0
e: 6003 str r3, [r0, #0]
10: d1f9 bne.n 6 <f+0x6>
12: 4770 bx lr
--- End code ---
Compare that to the version without:
--- Code: ---void g(int *x, int n)
{
int i;
for (i = 0; i < n; i++) {
x[i]++;
}
}
00000014 <g>:
14: 2900 cmp r1, #0
16: dd08 ble.n 2a <g+0x16>
18: 3804 subs r0, #4
1a: eb00 0181 add.w r1, r0, r1, lsl #2
1e: f850 3f04 ldr.w r3, [r0, #4]!
22: 3301 adds r3, #1
24: 4281 cmp r1, r0
26: 6003 str r3, [r0, #0]
28: d1f9 bne.n 1e <g+0xa>
2a: 4770 bx lr
--- End code ---
I don't see this as any worse than all other situations where lying to the compiler invokes undefined behaviour, eg. casting unaligned pointers and so on. Static code analyzers will use regular assert()s in their analysis, but I don't know offhand if any compilers do. Maybe in optimized debug builds?
hamster_nz:
--- Quote from: andersm on October 02, 2019, 11:15:52 pm ---It looks like you can convince GCC to perform the same optimization like so:
--- End quote ---
The ARM document was hinting that it would help with unrolling the loop too, avoiding quite a bit of code that is otherwise needed.
Navigation
[0] Message Index
[#] Next page
Go to full version