[MLton] runtime optimization flags?

[Matthew Fluet]

> Along these lines then, here is a patch. Three notes:
>
> 1. It reorganizes runtime/Makefile and bytecode/Makefile to introduce
>   an OPTFLAGS variable. Now that it is a variable, it can be overridden
>   as a parameter to make.

O.k.

> 2. This patch should have no effects on building MLton without
>   specifying OPTFLAGS="..." on the make command line, which is what
>   I will do when building the Fedora package. It should be safe to
>   merge into the trunk.


> 3. This patch is very conservative. There are certainly places where
>   flags can be moved from CFLAGS to OPTFLAGS. Between bytecode/Makefile
>   and runtime/Makefile, there are now FLAGS, CFLAGS, OPTFLAGS, and
>   DEBUGFLAGS. I suggest that we eliminate FLAGS, put all non-debug
>   and non-optimization flags into CFLAGS (like include paths, etc.),
>   put all tuning and optimization flags into OPTFLAGS, and put all
>   debugging build flags into DEBUGFLAGS. Then each make rule will
>   always specify CFLAGS and exactly one of OPTFLAGS or DEBUGFLAGS.
>   What do you think?

I think it is a fine idea.  On the x86_64 branch, I had already reoganized 
the makefile along these lines, along with moving the <src>/bytecode files 
into <src>/runtime so that there is a single Makefile that accumulates all 
the C compiler logic.  In that file, I have:
  FLAGS
  OPTFLAGS
  GCOPTFLAGS
  DEBUGFLAGS
  WARNFLAGS
  OPTWARNFLAGS
  DEBUGWARNFLAGS

Compiling gc.c gets more opt flags because we need to turn up the inlining 
parameters.  The *WARNFLAGS are because I want more warnings than are 
reported by just -Wall.  OPTWARNFLAGS includes warnings about disabled 
optimizations and disabled inlining; DEBUGWARNFLAGS is there to possibly 
turn on -Wunreachable-code; it doesn't make sense to include 
-Wunreachable-code in the OPT case, since there is much code only 
reachable when ASSERT is true.

> I also have a few minor makefile suggestions, but I will bring those up
> in a separate message.

Please do.