On 20/06/13 04:05, Max S. wrote:
> On avr32 target.
>
> Where does the speed difference come from between the two code
> fragments?
>
> struct foo buf[2];
>
> static inline void rx_int(uint8_t ch){
> LED_On(DEBUG_LED);
> //access to buf[ch]
> LED_Off(DEBUG_LED);
> }
>
> __attribute__((__interrupt__)) static void can0_int_rx_handler(void){
> rx_int(0);
> }
>
> __attribute__((__interrupt__)) static void can1_int_rx_handler(void){
> rx_int(1);
> }
>
>
> -----
>
> struct foo buf[2];
>
> __attribute__((__interrupt__)) static void can0_int_rx_handler(void){
> LED_On(DEBUG_LED);
> //access to buf[0]
> LED_Off(DEBUG_LED);
> }
>
> __attribute__((__interrupt__)) static void can1_int_rx_handler(void){
> LED_On(DEBUG_LED);
> //access to buf[1]
> LED_Off(DEBUG_LED);
> }
>
> In my case the second version runs 7% faster
> Shouldn't GCC in the above case be able to optimize buf[ch] access into
> direct accesses?
>
> just curious,
> Max Schneider.
>
Have you looked at the generated assembly code to see the differences?
Are you enabling optimisation? If you don't have at least "-O1", then
the "inline" in the first version will be ignored.
Even with optimisation enabled, if "rx_int()" is big enough then the
compiler may not inline it (especially if you use -Os). "inline" is
just a hint, not a command. You can use the "-Winline" flag to warn you
if "inline" has been ignored, and you can use
"attribute((always_inline))" to make inline into a command.
