F# compiler questions

A couple questions about the F# compiler

1) what does --noframework do? I compiled with it but I still needed .Net 4.0(I thought maybe it allowed a port to an earlier version?) Does it remove an F# dependancy?

2) What optimizations does the F# --optimize+ enable? all of them? if so, what are all of them?

3) What are the advantages/disadvantages of --tailcall? I know that x64 used to ignore .tailcall sometimes, I was curious if there were other problems or if those problems persist.

4) what is --crossoptimize and what does it do?

5) is there actually a fast sublan开发者_如何学Goguage or is that something really old??

Here is more detailed answer for question 2. F# compiler has many options for optimization, and --optimize+ enables most of them.

Reading from the compiler source code, here is the list of things --optimize+ enables. I also give you the hidden flags, in case you'd like to play with them. Of course, as it is not hidden and documented, this may change in a next release:

• JIT optimizations (--jit-optimize)
• local optimizations (--local-optimize), such as eliminatation of dead private bindings.
• cross-module optimizations (--crossoptimize+)
• allow inlining of lambda functions (--inlinethreshold:6). Big functions, whose size is greater than the given threashold, won't be inlined.
• sets ignoreSymbolStoreSequencePoints (there's no flag for this one)
• eliminate tuples allocated at call sites, because of uncurried functions (--detuple:1). See detuple.fs for detailed comment.
• do TLR (--tlr:1). I don't know what it is, but there are many comments in tlr.fs
• final simplify pass (--finalSimplify:1) applies some of the optimizations a second time (after other optimizations passes).

It looks like the --extraoptimizationloops:1 flag is not enabled by --optimize+. It does the same optimizations as the final simplify pass, but at another time. Might be useless.

For question 3, tail call optimization is very useful to prevent stack overflows (when you're doing many tail recursive calls). It makes debugging harder, so you might want to turn it off sometimes (this is the default in VS, in debug-mode).

Here are some quick answers based on memory. (You can always go spelunking through the compiler code for more detail.)

1) It allows targetting different frameworks, by not trying to implicitly use any mscorlib/FSharp.Core assemblies. So you use this when e.g. you explicitly reference the Silverlight mscorlib/FSharp.Core to target Silverlight.

2) Yes, nearly all of them, and I don't know what they all are. You might look at opt.fs.

3) Debugging - when using VS in "Debug" mode, --tailcalls- is passed to turn off tailcalls and preserve all stack frames to enable easier debugging.

4) FSharp can do inlining and other optimizations across assembly boundaries. This can be dangerous for published libraries because if A references B and A was compiled with crossoptimize and then deployed, and then someone changes/re-deploys B, it is possible A will "call" a method in the "old" B because that code from B was inlined into A and so A still has the "old B" code unless A is recompiled. This rarely matters in practice, but the 'typical' scenario if you have a number of dependent but independently-distributable F# libraries, you want to turn off crossoptimize to get rid of fragile dependencies.

5) That no longer exists.