MPLAB C Compiler for PIC24 MCUs and dsPIC DSCs ... - Microchip
MPLAB C Compiler for PIC24 MCUs and dsPIC DSCs ... - Microchip
MPLAB C Compiler for PIC24 MCUs and dsPIC DSCs ... - Microchip
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Using the <strong>Compiler</strong> on the Comm<strong>and</strong> Line<br />
TABLE 3-9: SPECIFIC OPTIMIZATION OPTIONS (CONTINUED)<br />
Option Definition<br />
-freduce-all-givs Forces all general-induction variables in loops to be<br />
strength-reduced.<br />
These options may generate better or worse code; results are<br />
highly dependent on the structure of loops within the source<br />
code.<br />
-frename-registers Attempt to avoid false dependencies in scheduled code by<br />
making use of registers left over after register allocation. This<br />
optimization will most benefit processors with lots of registers.<br />
It can, however, make debugging impossible, since variables<br />
will no longer stay in a “home register”.<br />
-frerun-cse-afterloop<br />
Rerun common subexpression elimination after loop<br />
optimizations has been per<strong>for</strong>med.<br />
-frerun-loop-opt Run the loop optimizer twice.<br />
-fschedule-insns Attempt to reorder instructions to eliminate <strong>dsPIC</strong>® DSC<br />
Read-After-Write stalls (see the “<strong>dsPIC</strong>30F Family Reference<br />
Manual” (DS70046) <strong>for</strong> more details). Typically improves<br />
per<strong>for</strong>mance with no impact on code size.<br />
-fschedule-insns2 Similar to -fschedule-insns, but requests an additional<br />
pass of instruction scheduling after register allocation has<br />
been done.<br />
-fstrength-reduce Per<strong>for</strong>m the optimizations of loop strength reduction <strong>and</strong><br />
elimination of iteration variables.<br />
-fstrict-aliasing Allows the compiler to assume the strictest aliasing rules<br />
applicable to the language being compiled. For C, this<br />
activates optimizations based on the type of expressions. In<br />
particular, an object of one type is assumed never to reside at<br />
the same address as an object of a different type, unless the<br />
types are almost the same. For example, an unsigned int<br />
can alias an int, but not a void* or a double. A character<br />
type may alias any other type.<br />
Pay special attention to code like this:<br />
union a_union {<br />
int i;<br />
double d;<br />
};<br />
int f() {<br />
union a_union t;<br />
t.d = 3.0;<br />
return t.i;<br />
}<br />
The practice of reading from a different union member than<br />
the one most recently written to (called “type-punning”) is<br />
common. Even with -fstrict-aliasing, type-punning is<br />
allowed, provided the memory is accessed through the union<br />
type. So, the code above will work as expected. However, this<br />
code might not:<br />
int f() {<br />
a_union t;<br />
int* ip;<br />
t.d = 3.0;<br />
ip = &t.i;<br />
return *ip;<br />
}<br />
© 2008 <strong>Microchip</strong> Technology Inc. DS51284H-page 49