ARM GCC pessimizer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm using arm-none-eabi-gcc 4.7.3, compiling for an M4 with the following
options:

-mcpu=cortex-m4
-mthumb
-mfloat-abi=hard
-mfpu=fpv4-sp-d16
-g3
-gdwarf-2
-gstrict-dwarf
-O3
-ffunction-sections
-fdata-sections
-std=gnu99
-fsigned-char
-D__VFPV4__
-specs=ewl_c_noio.specs

Here's a small code fragment, part of a FIR filter:

i = T00 + T10 + T20 + T30 + T40 + T50 + T60 + T70 
        + T80 + T90 + TA0 + TB0 + TC0 + TD0 + TE0 + TF0 
        - ((2 * T00) & -((s >>  0) & 1)) 
        - ((2 * T10) & -((s >>  2) & 1)) 
        - ((2 * T20) & -((s >>  4) & 1)) 
        - ((2 * T30) & -((s >>  6) & 1)) 
        - ((2 * T40) & -((s >>  8) & 1)) 
        - ((2 * T50) & -((s >> 10) & 1)) 
        - ((2 * T60) & -((s >> 12) & 1)) 
        - ((2 * T70) & -((s >> 14) & 1)) 
        - ((2 * T80) & -((s >> 16) & 1)) 
        - ((2 * T90) & -((s >> 18) & 1)) 
        - ((2 * TA0) & -((s >> 20) & 1)) 
        - ((2 * TB0) & -((s >> 22) & 1)) 
        - ((2 * TC0) & -((s >> 24) & 1)) 
        - ((2 * TD0) & -((s >> 26) & 1)) 
        - ((2 * TE0) & -((s >> 28) & 1)) 
        - ((2 * TF0) & -((s >> 30) & 1));

s is an unsigned int containing bits to be filtered. The T* symbols are
#defined constants. The compiler cleverly compiles "-((s >> #) & 1" into a
signed bit-field extract instruction, which picks out the bit, right
justifies it, and propagates it through all 32 bits. For a while, it was
sane enough to load the initial constant (the sum of all the T* symbols)
into a register, then for each bit, compute the mask, AND each one with
the corresponding constant, and subtract it from the register. Then, all
of a sudden, some other change prompted it to compute each mask and store
it into a local variable on the stack, and then use it later. Since there
are actually eight pieces of code like this, the result is huge,
memory-intensive, and slow.

What mechanism would prompt the compiler to do such a dumb thing? Is there
any optimization option that relates to this? I've tried -O3 and -O2,
tried various "register" declarations, dipped my toe into a few of the
specific optimizations listed in the docs, but there are a ton of them.
Any ideas?

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@xxxxxxxxxxxxx 
 





[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux