A QUICK INTRO TO PRACTICAL OPTIMIZATION TECHNIQUES

Transcription

1 A QUICK INTRO TO PRACTICAL OPTIMIZATION TECHNIQUES 0. NO SILVER BULLETS HERE. 1. Set Compiler Options Appropriately: Select processor architecture: Enables compiler to make full use of instructions which are supported by the processor Compiler performs processor-specific optimizations E.g., use -proc ARM7 Also use the most appropriate arch?? ( -arch N) (4 and 4T enables halfword instruction) Debugging Options Debugging options affect both codesize and performance significantly. To allow efficient debugging a varying level of optimizations is disabled. (Some optimizations produce code that cannot be described in debugging tables. Switch off debugging when code size and/or performance is important. Debug options: -g, -gr, -go -go increases code size by 7-15% Optimization Options: For time/speed (-Otime) For code size (-Ospace) Use appropriate ARM Procedure Call Standard or APCS options: -aps /wide -aps /fp -aps /swst/fp Recommendation: experiment with these options for the project: -Ospace -Otime -Otime -apcs /wide -Otime -go -Otime -g -Otime -gr -Otime -apcs /fp -Otime -apcs /swst/fp 2. Division & Reminder Divisions are typically implemented by calling a C-lib function: rt_sdiv, and rt_udiv Divisions are very expensive: cycles! (rule of thumb: Ncycles) Avoid it when possible, use algebraic substitutions: (x/y)> z can be replaced by x > (z*y) Combine both division and reminder when needed int combined_div_mod (int a, int b) {return (a/b) +(a%b); Use power of 2 division when possible. (eg. Use a/16 instead of a/15) (128 instead 100) Typedef unsigned int uint Uint div16u (uint a) { return a/16; Avoid Modulo (uses reminder) arithmetic when possible: Uint counter1 (uint count) { return (++count % 60); SW OPTIMIZATION (Courtesy M. Romdhane, Conexant) Page 1 of 8

2 Instead use this: Uint counter2 (uint count) { if (++count >= 60) count = 0; return (count); Division by a constant? Lookup tables 3. Conditional Execution All ARM instructions are conditional. Each instruction contains a 4-bit field which is a condition code. The instruction is only executed if the ARM flag bits indicate that the specified condition is true. Conditional execution is applied mostly in the body of if statements and while evaluating complex expressions with relational (<, ==, >) and Boolean operators (&&,!, ) Typically it starts with a compare instruction followed by a few conditional instructions It reduces the number of branch instructions and, therefore, improves code size and performance. 1 Branch instruction takes about 2.5 ARM7 cycles. Recommendation: To enable the compiler to use conditional instruction you need to keep the bodies of if/else statements as simple as possible. And relational expressions should be grouped into blocks of similar conditions: generate all flags and stream through the code without branch instructions 4. Compare with zero Can be avoided if the code can directly test the N, Z flags (Z: result is zero, N negative) ADD R0, R0, R1 CMP R0, #0 Produces identical N and Z flags as ADDS R0, R0, R1 However: the C language has no concept of a carry flag or overflow flag so it is not possible to test the C or V flag bits directly without inline assembler. The compiler supports the carry flag. 5. LOOPS Loop termination condition can cause significant overhead if written without caution. Always use count-down-to-zero loops and use simple termination conditions. Exampe: n! int fact1 (int n) { int i, fact =1; for (i=1; i <= n; i++) fact *=i; return (fact); int fact2 (int n) { int i, fact =1; for (i=n; i!= 0; i--) fact *=i; return (fact); fact2 can use SUBS instead of ADD/CMP. This is because a compare with zero could be optimized away. Saves one instruction in the loop. SW OPTIMIZATION (Courtesy M. Romdhane, Conexant) Page 2 of 8

3 Also on fact2 the variable n does not need to be saved across the loop so a register is also saved. this eases register allocation and leads to more efficient code elsewhere in the function (2 more instruction saved) This observation (of initializing the loop counter to the number of iterations required and then decrementing down to zero) also applies to while and do statements. 6. LOOP UNROLLING Small loops can be unrolled for higher performance at the expense of increased codesize. When a loop is unrolled, the loop counter needs to be updated less often and fewer branches are executed. If the iteration number is small a loop can be fully unrolled and the loop overhead completely disappears. Not supported by the compiler, should be done manually int countbit1 (uint n) { int bits = 0; while (n!=0) { if (n & 1) bits++; n >>=1; return bits; Here if we assume ARM7, then checking a single bit takes 6 cycles, and the code size is only 9 instructions int countbit1 (uint n) { int bits = 0; while (n!=0) { if (n & 1) bits++; if (n & 2) bits++; if (n &4) bits++; if (n & 8) bits++; n >>=4; /* shift right by 4*/ return bits; The above code checks 4 bits at a time, taking on average 3 cycles per bit. However, the code size is 15 instructions. 7. REGISTER ALLOCATION This is a process where the compiler allocates variables to ARM registers, rather than to memory. This has a dramatic effect on both speed and memory as these variables can now be accessed quickly without needing instructions to transfer them to/from the memory. You can write code which enables the compiler to achieve a more optimal register allocation. All basic interger, pointer and floating-point types, fields of structures and complete structures can be allocated to registers. A variable may be allocated to a register if: it is a local variable or a function parameter and its address in never taken, or its address is taken but not assigned to another variable. A field in a structure may be allocated to a register if: it is declared locally or a function parameter and SW OPTIMIZATION (Courtesy M. Romdhane, Conexant) Page 3 of 8

4 the structure is not assigned directly with the result of a function call, and neither the address of the structure nor any of its filds is taken, or if any of these addresses is taken, it is not to another variable. 8. ALIASING/POINTERs Pointer must be used carefully or poor code can be produced If the address of a variable is taken, the compiler must assume that the variable can be changed by any assignment through a pointer or by any function call That makes it impossible to put it into a register, This is also true for Global Variables, as they might have their address taken in some other function. Pointer Aliasing Problem. Some other compilers ignore this but ARM compiler does not (because this rule is part of the ANSI/ISO standard. (ignoring can produce untraceable bugs) Rules of thumb on local and global variables: Avoid taking the address of local variables avoid global variables avoid pointer chains 9. LOCAL VARIABLES: Sometimes it is necessary to take the address of variables, example if they are passed as a reference parameter to a function. This means that these variables can not be allocated to registers. SOLUTION: Make a copy of the variable and pass the address of that copy instead. EXAMPLE: Void f(int *a); Int g(int a); Int test1(int I) { f(&i); address of I is taken cannot allocate reg /*now use 'I' extensively */ I += g(i); I += g(i); Return I; int test2(int I) { int dummy =I; f(&dummy); I=dummy; I += g(i); I += g(i); Return I; 10. GLOBAL VARIABLES Global variables are never allocated to registers (unless the global_reg feature is used). Global Variables can be changed by assigning the indirectly using a pointer, or by a function call. Hence the compiler cannot cache the variable in a register extra (often unnecessary) loads and stores when globals are used. Rule of thumb: NEVER USE GLOBAL VARIABLES IN A CRITICAL LOOPs. if a function uses global variables heavily, when possible and when it makes sense: copy those global variables into local variables so that they can be assigned to registers. SW OPTIMIZATION (Courtesy M. Romdhane, Conexant) Page 4 of 8

5 Of course, this is possible only if those globals are not used by any of the function which are called. EXAMPLE: Int f(void; Int g(void); Int errs; Void test1(void) {errs += f(); errs += g(); void test2(void) { int localerrs = errs; localerrs += f(); localerrs += g(); errs = localerrs; Here, test 1 must load and store the global errs value each time it is incremented, whereas test2 stores localerrs in a register and needs only a single instruction. 11. POINTER CHAINS Example: Typedef struct { int x, y, z; Point3; Typedef struct { Point3 *pos, * direction; Object; Void InitPos1(Object *p) { p pos x = 0; p pos y = 0; p pos z=0; This code must reload p pos for each assignment. Instead, cache p pos in a local variable: Void InitPos2(Object *p) { Point3 *pos = p pos; pos x = 0; pos y = 0; pos z = 0; An alternative is to avoid pointers in the first place by including Point3 structure in the Object structure. 12. LIVE VARIABLES & SPILLING These have effect on the quality of register allocation. ARM has 14 integer registers available. The ARM Compiler supports live-range spilling: LIVE RANGE OF A VARIABLE: last assignment & usage {all statements Next assignment In this range the value of the variable is valid, thus alive. In between live ranges the value of a variable is not needed: it is dead. So its register can be reused by other variables, resulting in allocation of more variables to registers. The number of registers needed for register-allocatable variables is at least the SW OPTIMIZATION (Courtesy M. Romdhane, Conexant) Page 5 of 8

6 number of overlapping live ranges at each point in a function. If this exceeds the number of registers available, some variables must be stored to memory temporarily. This process is called SPILLING. The compiler spills the least frequently used variables first. SPILLING CAN BE AVOIDED BY 1. Limiting the maximum number of variables. 2. Keep expressions SIMPLE and SMALL. 3. Minimize the number of variables in a function. 4. Subdivide large functions into SMALLER, SIMPLER ones 5. using register for frequently used variables etc 13. DECLARING VARIABLE TYPES Use the most appropriate variable types - char, short, int, long, signed and unsigned, float, double. For local variables, when possible avoid char & short as local variables. (The compiler needs to reduce the size of local variable to 8 (shift right by 24) or 16 bits (shift right by 16). These operation can be avoided if int is used, thus optimizing both the speed and the codesize. 14. FUNCTION DESIGN General Rule: keep functions small and simple. This enables the compiler to perform optimizations, such as register allocation, more efficiently. Function Call Overhead: Relatively small - The minimal call-return sequence is BL MOV pc, lr (~ 6 cycles) - The Multiple load and store instruction (LDM, STM) (PUSH, POP in Thumb instruction set) reduce the cost of function entry and exit when some registers need to be saved. - Under the APCS, up to 4 words of arguments can be passed to a function in registers. If more needed (e.g., 5 th and 6 th are passed on the stack), then there is additional cost of storing these words in the calling function and reloading them in the called function. Int f1(int a, int b, int c, int d) { return a + b+ c + d; int g1 (void) { return f1(1, 2, 3, 4); Int f2(int a, int b, int c, int d, int e, int f) { return a + b+ c + d + e + f; int g2 (void) { return f1(1, 2, 3, 4, 5, 6); Here, the 5 th and 6 th parameters are stored on the stack in g2, and reloaded in f2, costing 2 Memory accesses per parameter. Therefore, Use four or less arguments for small functions if more arguments are needed, make sure that the function does significant amount of work pass pointers to structures instead of passing the structure itself use value_in_regs specifier, which can be used to return structures of upto 4 words in registers. Otherwise, normally structures are returned on the stack. Example: SW OPTIMIZATION (Courtesy M. Romdhane, Conexant) Page 6 of 8

7 typedef struct {int hi; uint lo; int64; //low word unsigned value_in_regs int64 add64(int64 x, int64 y) // see specifier { int64 res; res.lo = x.lo + y.lo; res.hi = x.hi + y.hi; if (res.lo < y.lo) res.hi++; // carry from low word return res; void test(void) { int64 a, b, c, sum; a.hi = 0x ; a.lo = 0xF ; b.hi = 0x ; b.lo = 0x ; sum= add64(a,b); c.hi = 0x ; c.lo = 0xffffffff; sum = add64(sum c); Here, by using value_in_regs, the code size is 52 Otherwise it would have been 160 bytes! LEAF FUNCTIONS These are functions that do not call any other function. These can be efficiently compiled with ARM compiler, since we do not need to perform the usual saving and restoring of registers. maximize use of leaf functions TAIL CONTINUED FUNCTION When a func ends with a call to another function, the call can be converted to a branch to that function. This is called tail continuation. This usally saves stackspace and branch. PURE FUNCTION The result they return depends only on their arguments (math func). Therefore, there are no side effects: cannot read or write global state by using global variables or indirecting through pointers use pure pure int square (int x) { return x * x int f(int n) { return square(n) + square(n); INLINE FUNCTIONS Inline functions do not have call overhead, and a lower argument evaluation overhead. Therefore, more compiler optimizations are possible (e.g., Combine ADD + MUL MLA: Mul accumulate instruction inline: Each call to an inline function is substituted by its budy, instead of a normal call. Faster code, larger codesize. FUNCTION DEFINITION Placing function definitions before their use can produce better code. It allows the compiler to analyze the register usage of the called function. This is a simple form of interprocedural optimization (where opt are carried out between functions). Finally, where possible, use table lookup approximations, rather than function calls. 15. USE MACROS FOR PORTABILITY: #ifdef arm SW OPTIMIZATION (Courtesy M. Romdhane, Conexant) Page 7 of 8

8 # define INLINE inline # define VALUE_IN_REGS value_in_regs #define PURE pure #else # define INLINE # define VALUE_IN_REGS # define PURE #endif SW OPTIMIZATION (Courtesy M. Romdhane, Conexant) Page 8 of 8