Undocumented optimization compiler directives
lazarus / 62-General

----------------------------------------------------------------------
Marladu · 2015-01-21 15:41

Digging through the compiler code I happened to find compiler
directives related to optimization that are accepted by the compiler
but that I don't know what they do. Here's the list (found in
globtype.pas):

{$OPTIMIZATION STRENGTH}: unknown?
{$OPTIMIZATION SCHEDULE}: unknown?
{$OPTIMIZATION AUTOINLINE}:guessing it's like delphi {$inline auto}?
what rules does it follow?
{$OPTIMIZATION USERBP}: guessing it's a 64bit version of
{$OPTIMIZATION USEEBP}?
{$OPTIMIZATION FASTMATH}, {$OPTIMIZATION DEADVALUES}, {$OPTIMIZATION
DEADSTORE}: nicely documented at
http://wiki.freepascal.org/FPC_New_Features_Trunk#Code_generator

 So, anyone got details on what the first 4 do?

----------------------------------------------------------------------
engkin · 2015-01-21 16:41

I don't expect you to see answers here. Try a suitable mailing list or
move your post under Free Pascal where FPK is a moderator.

Quote from: Marladu on January 21, 2015, 04:41:34 pm{$OPTIMIZATION
USERBP}: guessing it's a 64bit version of {$OPTIMIZATION USEEBP}?
Yes.

----------------------------------------------------------------------
marcov · 2015-01-21 16:43

Strength is probably "Strength Reduction" (look up in wikipedia),
hoisting code out of loops.

Schedule is probably instruction level scheduling.

----------------------------------------------------------------------
Marladu · 2015-01-21 17:20

Darn, I though I had posted in freepascal-general, my bad, apologies.
Still, the answers are plenty good and appreciated, thanks!

 I had forgotten to write about {$OPTIMIZATION FORCENOSTACKFRAME} but
it doesn't seem to do anything at this time, I'm guessing when
implemented it will force a nostackframe on every function where it
works. For {$OPTIMIZATION AUTOINLINE} I tested it and it works,
inlining small functions it can even without the inline function
modifier, just don't know what rules it follows. Only did limited
testing with {$OPTIMIZATION FASTMATH} but so far it looks very very
excellent at improving speed of unoptimized floating point operations,
and I didn't observe any precision loss as warned in those small
tests.