Hi John
I try to stay as much at the C-level where the details of parameter passing and stack are left up to the compiler. There shouldn't be any code in the project (apart from a very small amount of assembler and library, if used) which is compiler setting dependent.
However, as you have seen, the operation of the compiler does influence code size and also operational speed (as does the optimiser setting used).
I tend to use ALWAYS use full optimisation for space (also for debugging*) based on the fact that it is best to test with the same code and characteristics which will be used later in the release version, and the fact that also optimisation for size will usually produce quite good optimisations for speed (apart from things like loop roll out where loops will be expanded to a series of blocks of the content to avoid any loop variable checking and flow control change - but at the price of code size).
If minimum code size is your priority and certain setting allow this to be improved I would stick with it. It is up to the compiler to ensure that the C-code works, irrespective of the exact compiler settings - if it runs during normal tests this will probably already have proved that it is suitable.
*You probably already know that debugging with CodeWarrior with full optimisation can be tricky. I tend to switch on mixed mode display when doing this so that the assembler code can be seen, which sometimes makes more sense when the program flow jumps around. It also enables single stepping in the assembler code in switch states from FLASH (this doesn't tend to work otherwise due to limited hardware breakpoints). However I also try to avoid the debugging of code on the target which is not very hardware specific - which is generally a very small part of real projects. Instead general C code can be tested and debugged in the uTasker simulator (VS) much easier and more efficiently.
Regards
Mark