Just Curious: When has anyone "HAD" to use {$OPTIMIZATION OFF}

[Ten_Mile_Hike]

I'm curious as to if and in what circumstances anyone here has had to actually
use {$OPTIMIZATION OFF} when compiling optimized source code. Was it
because the compiler produced buggy code; if so was this in old compiler
releases or just recently?

{$OPTIMIZATION OFF} // Disable optimizations
procedure My_Procedure;
begin
 Some Code Here
end;
{$OPTIMIZATION ON} //Reenable optimizations

[Martin_fr]

Not exactly in the way of your example, but I have...

Several cases of

Code: Text  [Select][+][-]

1. {$IF FPC_Fullversion=30202}{$Optimization NOPEEPHOLE}{$ENDIF}

To prevent a bug in the peephole optimizer from generating bad machine code for the units in question.

I also have several

Code: Text  [Select][+][-]

1. {$IFDEF NOINLINE}{$INLINE OFF}

so I can define that for debugging.

I haven't run into any issue where I needed a debug session with some optimised, and some debug-able code. But if that would happen, it might lead to exactly your case.

I could also imagine specific other optimisation to be turned off (unconditionally) for some sections of code. Maybe

Code: Text  [Select][+][-]

1. {$Optimization noORDERFIELDS}

Though I would likely prefer other methods (like embedding the relevant data in a record)

[n7800]

Searching in Lazarus sources gives few results in debugger tests.

Searching in OPM gives a lot of results. Here is one example in BGRABitmap:

Code: Pascal  [Select][+][-]

1. {$PUSH}{$OPTIMIZATION OFF} // avoids internal error 2012090607
2. procedure TCustomRenderer3D.SetProjection(const AValue: TProjection3D);
3. begin
4.   FProjection := AValue;
5.   FProjectionDefined := true;
6. end;
7. {$POP}
8.  

I also remembered seeing optimization disabled to speed up execution in LazUtils:

Code: Pascal  [Select][+][-]

1. function SameMethod(const m1, m2: TMethod): boolean;
2. begin
3. {$PUSH}  {$BOOLEVAL ON}
4. // With a full evaluation of the boolean expression the generated code will not
5. // contain conditional statements, which is more efficient on modern processors
6.   Result:=(m1.Code=m2.Code) and (m1.Data=m2.Data);
7. {$POP}
8. end;
9.  

[Paolo]

this could be a problem for some mathematical calculations, see for example wiki "Kahan summation". the "smart" optimizer could oversimplify the expression completely defeating the purpose of the algorithm

[Martin_fr]

Actually I saw this
procedure TLazMonitor.Acquire;

Code: Pascal  [Select][+][-]

1.       {$OPTIMIZATION OFF}
2.       for j := 0 to Waitcount-1 do
3.         begin
4.         end;
5.       {$POP}
6.  

Part of a spin-lock. So the thread needs to do a couple of cycles of nothing on the CPU. It must not use sleep, as it does not want to give up its runtime.

But an optimizer could replace an empty loop with nothing.

[Mr.Madguy]

I have never done it in Delphi/FPC, but I've done it in C++. But it's mostly connected to using inline asm and complete lack of runtime code. For example code like this:

Code: Pascal  [Select][+][-]

1. for I := 0 to 9 do A[I] := B[I];
2.  

is turned into memcpy call. And as runtime code is stripped, it causes unresolved references. Sometimes complier removes code, if it thinks, that it does nothing. For example if data is passed to function as pointer, compiler may think, that it does nothing.

[circular]

It may be counterintuitive, but $OPTIMIZATION ON is only a synonym of $OPTIMIZATION LEVEL2, as explained in FPC documentation. So it would enable optimizations even if they are turned on in the package/project options. I've confirmed this experimentally.

To locally turn off optimizations while respecting project options, one can do:

Code: Pascal  [Select][+][-]

1.     {$OPTIMIZATION OFF}
2.     SetLastCoord(ArcEndPoint(arcDef));
3.     {$OPTIMIZATION DEFAULT}

This examples comes from BGRABitmap.

[Thaddy]

Imho, level2 optimizations are still - as documented - debugger friendly, but higher optimizations can - as documented - have side effects and that is in some cases an issue. There are still bugs in the optimizer, which is another reason to turn them off if the results - not in speed - between O- and O4 differ. And that will happen. Also, like many here, there is the matter of specific optimizations, which need care during development. So in general there is always the case to turn optimizations off during development.
You need to compare both. Never write software with max optimization on ever. You would be fooling yourself.

[BeniBela]

It may be counterintuitive, but $OPTIMIZATION ON is only a synonym of $OPTIMIZATION LEVEL2, as explained in FPC documentation. So it would enable optimizations even if they are turned on in the package/project options. I've confirmed this experimentally.

Does this mean that if Level 4 optimizations are enabled on the command-line parameter and you use $OPTIMIZATION ON, it would disable them to revert to Level 2?

[creaothceann]

Does this mean that if Level 4 optimizations are enabled on the command-line parameter and you use $OPTIMIZATION ON, it would disable them to revert to Level 2?

Apparently it does...

ON
    Switches on optimizations, corresponding to level 2 optimizations.
OFF
    Switches of [sic] all kinds of optimizations.
DEFAULT
    Returns to default (i.e. command-line or config file) specified optimizations.

[PascalDragon]

Imho, level2 optimizations are still - as documented - debugger friendly, but higher optimizations can - as documented - have side effects and that is in some cases an issue.

Level 2 optimizations can already lead to code that might lead to issues in the debugger, but don't have side effects. E.g. the REGVAR optimization might be enabled there which can lead to less stack usage or reuse of the same register for different variables without the variable being stored anywhere if the lifetime permits it. After all Lazarus only declares -O1 as more or less debugger friendly for a reason...

[Martin_fr]

Imho, level2 optimizations are still - as documented - debugger friendly, but higher optimizations can - as documented - have side effects and that is in some cases an issue.

Level 2 optimizations can already lead to code that might lead to issues in the debugger, but don't have side effects. E.g. the REGVAR optimization might be enabled there which can lead to less stack usage or reuse of the same register for different variables without the variable being stored anywhere if the lifetime permits it. After all Lazarus only declares -O1 as more or less debugger friendly for a reason...

Indeed.

Level 2 opts provide still mostly intact line-info. Of course
- inlined code can't be stepped, or have breakpoints
- break, exit statements may merge with the line before them (though that happens in level 1 already), but level 2 may optimize more lines away

But, as for variables, values can't be trusted much (well at least not local vars). If they are not in registers, they may still delay updating their memory. So the value may show only once stepped an extra line away.
But if they are in registers, they show the value of that register, regardless if it currently is that value. That is, a single register is often used for several vars (in different lines of code), yet the compiler just says "variable foo is in reg x" as if for the whole time.

[ad1mt]

I had a problem where inlining of functions plus -O3 optimisation caused the compiler to crash.
So I had to either disable inlining of functions, or set -O2 to get an optimised executable.
CORRECTION...
I had a problem where inlining of functions plus -O2 optimisation caused the compiler to crash.
So I had to either disable inlining of functions, or set -O1 to get an optimised executable.

[n7800]

This was already mentioned above, but I think it needs to be made more prominent. Using $PUSH/$POP directives for optimization directives doesn't work, see the FPC issue.

Just for information, for anyone who finds this thread.