ARM-CGT: TI-CGT-ARM 20.2.7 Compiler Optimization

Hi!

The effects are described in the "Invoking Optimization" sub-chapter of TI ARM compiler manual.  When you disable optimization, higher level optimizations are completely disabled.  These optimizations have the most impact on the generated code.  However, there are low-level, target-specific optimizations that are done outside of the optimizer that are determined by the specific Speed vs. Size trade-off selected, but really aren't as effective as when the higher level optimizations are enabled.  These are done because the compiler has to make target-level choices that might still inadvertently impact codesize or performance, and so the user can adjust that as necessary.  In general, we advise to use the default setting.

-Alan

Hi Alan,

We are working based on the aviation application so it is high-safety. We need to know what are the optimization be made on the code? is it possible? 

Hi Muhammet -- My language was imprecise in that these low-level, target specific "optimizations" area really target-level choices the compiler has to make. There is no list of these choices available.  For safety, it's important to focus on higher level optimizations that have broad impact over the generated code (which are disabled here).  Those optimizations are listed in the compiler manual linked above.

Hi Alan, I cannot take a response my question my question is that, when we choses opt_for_speed = 0, are there any effect to sizes of the code? or are there any optimization? if compiler make optimization when we set to speed = 0, I need to know where does optimization affect the code.

I presume your overall goal is to ...

Muhammet Bagoglu said:

turnnig off the all compiler optimization

Of course, the main way to do that is with the setting --opt_level=off.  Because the option --opt_for_speed is in the same options dialog, you presume there is some way to turn it off.  It doesn't make sense to think of it that way.

Most optimizations remove instructions, and thus improve both speed and size.  But there are a few optimizations which improve one while degrading the other.  Two prominent examples are function inlining and loop unrolling.  So a user can control the speed vs size trade-off of such optimizations, the compiler supports the option --opt_for_speed=value.  Lower values favor smaller size at the expense of slower speed.  Higher values favor faster speed at the expense of larger size.  There is no setting that corresponds to off.

What may make the most sense is to use the setting that corresponds to the compiler default when --opt_for_speed is not specified.  That setting is --opt_for_speed=1.

Thanks and regards,

-George

You are welcome to reject a reply I marked resolved.  But before I can reply further, I need to know why you rejected it.

Thanks and regards,

-George

Hi George,

First of all, I'm sorry to cannot give response your message.

The reason for rejecting is that your answers are not appropriate for me. Because, if I proceed with default values, I will have optimized my code. But as I mentioned above, I do not want a software in addition to the codes I wrote in a software developed for aviation on a safety application. so your answers are insufficient and invalid.

In addition, as you know, processors such as TMS570 are specially developed for safety-critical missions. But the code we want to embed for this processor suggests optimization. Don't you think there is a contradiction?

Turning off optimization in safety-critical software should be under the user's control.

Muhammet Bagoglu said:

Because, if I proceed with default values, I will have optimized my code.

If that is what you mean by optimization, then all compilers optimize, no matter what options are used.

Just as a thought experiment, presume the compiler does not have the option --opt_for_speed.  Presume further the compiler implementer gives no explicit thought to the trade-off between size and speed.  Even under those unrealistic conditions, the choice between size and speed still occurs.  Because it is impossible to avoid this choice.  The TI Arm compiler not only makes this trade-off explicit, it gives the user a way to influence this trade-off by means of the option --opt_for_speed.

Thanks and regards,

-George

You also have no control over how the compiler translates C code into assembler code even without optimization. There could easily be a bug in that, too.

And compilers have *always* done silent optimizations such as compile time constant calculations.

I don't agree your "all compilers optimize" response. Because we can close optimization turn-off in the TI-Clang compiler.

we have a object code analysis for controlling translated C code into assembler code.

Well, in "The Elements of programming style", ca 1978, Kernigham and Plauger say:

"Many compilers will do the trivial optimization of moving constants out of a loop without even being asked. (By knowing too much, you may even impede their efforts.) But even for a simple minded compiler, the first two lines [I = K+1; Temp = C(I)] should certainly be combined into Temp = C(K+1)."

Muhammet Bagoglu said:

we can close optimization turn-off in the TI-Clang compiler

tiarmclang -O0 and armcl --opt_level=off are very similar in that they disable all the large scale optimizations.  But neither of those options disables 100% of the compiler optimization.  All other compilers are very similar in this regard.

Thanks and regards,

-George