Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Flambda manual chapter #503
User documentation about Flambda for the manual.
This doesn't constitute developer documentation. That is intended to be provided by the source code itself and the comments in that code. We will try to do some more improving of comments before the 4.03 release.
In this GPR there is a hack in fix_index.sh (so it would work for me) which I shall revert before merging this.
Impressive amount of work (both flambda and this manual).
The last two questions are in fact related, so let's address those first. There isn't any support at the moment for saying things like "function foo isn't exposed in the interface of this module and isn't used inside, so we'll delete it before optimisation". It's possible something like that could be thought about in the future though.
I have plans for a whole-program mode which will recompile at link time based on the intermediate representations in the .cmx files (with all .cmx files being required). We could have a flag to suppress normal object file generation when planning to link in that mode. The main advantage this will give is that dead code elimination will happen at the Flambda stage basically automatically. Proposals for other means of large-scale dead code elimination are highly involved.
The problem is that it so heavily depends on what the code actually is that generalised benchmark numbers may be misleading. I think we should perhaps leave something like that until 4.04, when we will have received more information on general use cases in the wild.
Suggestions received from William via email, which I shall look at:
"Detailed descriptions of each flag are given in the sections that follow." : I would replace by : "Terms and concepts used here are better described in the following sections".
"advanced options" : do you mean it is even less used that "less commonly-used options" ?
"The set of command line flags relating to optimisation should typically be specified to be the same across an entire project." why not give a typical ocamlbuild command. ? In the mean time, I see you are from Janestreet, so you would not do that as you use other tool ...
"Flambda-specific flags are silently accepted " : as it is silent only for benchmark purposes, why not make warnings by default, and add an option to make them silent when performing benchmanking ?
"-rounds" : refer to the related chapter 20.2.1
"If the first form is used, the value will apply to all rounds.If the second form is used, zero-based round integers specify values which are to be used only for those rounds. " : what is first/second forms ? Maybe reformulating this with examples would be clearer.
can also be written :
Same thing for the module. I'll let you decide if it's better or not. :)