[MLton] runtime optimization flags?

[Matthew Fluet]

> 1. Could changing the optimization flags of things in runtime/ and
>    bytecode/ cause correctness problems? I know there are issues with
>    aliasing for some files. But what about the align-functions things?
>    Would the garbage collector or stack manipulating things get
>    confused?

We have had problems in the past compiling some of the runtime/basis/Real 
functions with -O2, because of the casts between double and a struct of 
two words.  But, we explicitly 'downgrade' the flags to -O1 
-fno-strict-aliasing, so that would be maintained even if the general 
flags were initialized to RPM_OPT_FLAGS.

I don't believe that the other optimization flags serve any correctness 
purpose.  The garbage collector only manipulates the ML stack, it doesn't 
really care about what's going on with the C stack; so, the alignment of 
functions ought not to matter.  It could very well be that the various 
-falign-* optimization flags aren't doing much anymore; we picked them up 
from some PolySpace mods in 2002.

> 2. Might changing the optimization flags cause performance problems?
>    Why is -O1 often used instead of -O2? I know the stack protector
>    flags will cause a slight performance hit. Could MLton possibly
>    benefit from these flags? (Detect some C bugs?)

As far as I can tell, -O1 is used for three groups of runtime files:
  1) gdtoa
  2) basis/Real/*
  3) *-gdb.o

The first two groups correspond to double intensive functions; we turn 
down the optimization level for the reasons given above.  For the last 
group, we turn down the optimization to make gdb debugging easier.

So, the vast majority of the runtime system for non-debug mode is compiled 
with -O2.

The stack protection stuff probably helps a little; I discovered one 
broken sprintf because one of the *BSD platforms has stack protection as a 
default in the gcc flags.  In a typical SML program (or, at least one that 
isn't memory bound), garbage collection and runtime functions ought to be 
< 30% of runtime, so paying more there won't be that apparent.

> As reference, on my i386 FC6 machine, the flags are "-O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
> -fasynchronous-unwind-tables".

These seem reasonable, if extraneous for a program like mlton that doesn't 
use exceptions or (many) stack allocated buffers.

> If changing these things is ok, then would it also make any sense to
> change the /usr/bin/mlton script to have these RPM_OPT_FLAGS as defaults
> for when MLton is invoked? I suspect there is little benefit here.

For an x86 platform that uses the native codegen, then the RPM_OPT_FLAGS 
would have little effect, positive or negative.  On other platforms that 
use the C codegen, then -O2 becomes a little suspect: you are asking gcc 
to optimize code that has already been heavily optimized by the mlton 
optimizer and that (probably) doesn't abide by C aliasing rules.

> I'm leaning towards leaving things as they are, but I just want to have
> some justification and documentation for my choice.