[MLton] runtime optimization flags?

[Adam Goode]

Matthew Fluet wrote:
> 
> These seem reasonable, if extraneous for a program like mlton that
> doesn't use exceptions or (many) stack allocated buffers.
> 
> 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.
> 



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.

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 also have a few minor makefile suggestions, but I will bring those up
in a separate message.


Thanks,

Adam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://mlton.org/pipermail/mlton/attachments/20061118/bcd600eb/signature.pgp