You could subscribe to the gcc-help @ gcc.gnu.org mailing list, see

http://gcc.gnu.org/lists.html#subscribe

and hope that some arm-gcc expert is around.

Please keep in mind that it's much more helpful when you provide code 
that can be compiled, i.e. compose a small test case that passes 
compilation (e.g. with -c) and does not contain unknown parts (like your 
private deadbeef.h header or missing definition(s) of T*).

Johann L. wrote:
> You could subscribe to the gcc-help @ gcc.gnu.org mailing list, see
>
> http://gcc.gnu.org/lists.html#subscribe
>
> and hope that some arm-gcc expert is around.

I have asked over there, too. Apologies to those who've seen this same 
question over there--I don't know how much commonality there is between 
the two forum memberships.

> Please keep in mind that it's much more helpful when you provide code
> that can be compiled, i.e. compose a small test case that passes
> compilation (e.g. with -c) and does not contain unknown parts (like your
> private deadbeef.h header or missing definition(s) of T*).

The reason I didn't is that if I wrap that fragment in a function and 
compile it, it generates glorious, beautiful, efficient code. But when I 
include it in a much larger function, it turns into a bloody mess. I can 
fix it by factoring the function into smaller ones, but this is realtime 
DSP, and I can see that it should be easy to do the whole thing (not 
just this fragment) in the available register set. And indeed, it 
originally did just that, but in the process of adding to my code, I 
seemed to cross some complexity threshold where the result suddenly went 
from wonderful to
horrible.

It looks like a register pressure issue, but I can't imagine what goal 
it is trying to achieve. It suddenly decided to start computing 
subexpressions, storing them into invented stack-based temporaries, and 
then going back and computing the final expression values based on these 
temporaries. This bumped by stack usage from a modest 16 or 20 bytes 
(for a few explicit local variables) up to somewhere between 100 and 200 
depending upon what other options I fiddled with, and it interspersed 
dozens and dozens of completely unnecessary loads and stores.

Were these "common subexpressions"? Well, some were common to multiple 
switch cases (the posted fragment was one switch case), but none that 
would ever actually get used more than once. I tried -fno-gcse, and that 
didn't help.

Another aspect of the problem is that it seems to want to schedule 
instructions as though it were compiling for some machine with a really 
deep pipeline, which the M4 is not. It frequently launches a bunch of 
loads, and then uses the results, when it could do the same work in 
fewer registers if it deferred the loading until it needed the data, or 
even one instruction before it needed the data. Since my data is in 0WS 
RAM, this isn't helpful.

So I'm just wondering if anyone has seen anything like this before, and 
knows what optimization knob to twiddle to make it go away.

Does the GCC Thumb2 backend have a reputation for being good or bad? I 
think the x86 backend is amazingly good, and I had good luck with old 
ARM7 backend years ago. This Kinetis K70 project is my first Thumb2 
experience, and so far the compiler is like Dr. Jekyll and Mr. Hyde.