Add -flambda/-no-flambda compile-time options to ocamlopt#699
Add -flambda/-no-flambda compile-time options to ocamlopt#699alainfrisch wants to merge 2 commits intoocaml:trunkfrom
Conversation
The configure-time option determines the default mode (and the one used to compiled stdlib and compiler-libs), but the restriction that code compiled with/without flambda (as determined at configure-time) cannot be linked together is lifted. The same magic number is used in .cmx files for flambda and non-flambda mode. Previously, different magic numbers were used, which leads to potentially cryptic error messages when trying to mix the two modes. When compiling a unit B which imports A.cmx, in different mode w.r.t. flambda, the cross-module optimization information from A.cmx are ignored (just as if A.cmx had been obtained by -opaque). This also trigger a new warning 61 explaning the situation (instead of the above-mentioned error message). In addition, this removes some code duplication between asmpackager.ml and compilenv.ml.
utils/config.mlp
Outdated
| else | ||
| "Caml1999Z014" | ||
| and cmx_magic_number = "Caml1999Y015" | ||
| and cmxa_magic_number = "Caml1999Z014" |
There was a problem hiding this comment.
We probably don't want to decrease the maximum magic. Future compiler versions would risk reusing Caml1999Y016
There was a problem hiding this comment.
Good point, thanks. I'm now using the magic numbers that used to be for the flambda case.
There are only two places which issue these messages - objinfo.ml and compilenv.ml. In compilenv.ml to make things clear one can just add "(or outdated format)" to error message at the very end of the file - Not_a_unit_info. This will cover both .cmx and .cmxa files. Of course format may be too new, but it will give a hint in most situations. |
|
I would like to discuss this before any merge (I am on vacation at the moment). |
|
(In particular this is probably related to #620.) |
…king reusing those values later.
Well, the two PRs could be combined so that a single compiler could be used for flambda and non-flambda projects by installing two versions of the stdlib. That said, in practice, people are likely to use external packages (installed e.g. by OPAM), and I don't think we want to go to the direction where all installed packages would have to build and install multiple versions. |
|
@chambart, @mshinwell, @lpw25 : do you see big obstacles in allow a limited form of cross-module optimization between flambda and closure modes? My guess is that supporting direct function calls, even if not inlining, should be rather simple, no? |
Ping @mshinwell. |
|
Sorry, I failed to look at this one, and I'm about to be away again. @alainfrisch To address your most recent comment, my general feeling is that we need to be looking to a world in which the old Closure code is removed. To that end, given how stretched we are on manpower, I think it's a much better use of time to work on speed improvements to Flambda rather than trying to achieve interoperability. I will let @lpw25 and @chambart comment. |
|
This specific PR is rather simple and low-risk. Do you have any objection on principle on having it integrated? |
|
I don't, as long as it is quite clear what are the limitation. Also there might be some reason for removing it later, if for instance the ABI has to change. It should be clear that it might happen. |
|
Ok, our flambda gurus seem reluctant to the idea of allowing flambda and non-flambda code to interact (and I can see that this would be difficult for support if flambda changes the ABI). I don't think it is meaningful to push in this direction, then. |
Cleanup fiber implementation and add documentation
ce76e02 flambda-backend: Bugfix for type_application (ocaml#746) 44f3afb flambda-backend: PR580 for main branch (ocaml#743) b851eaa flambda-backend: Backport first part of ocaml/ocaml PR10498 (ocaml#737) fafb4bd flambda-backend: Fix return mode for eta-expanded function in type_argument (ocaml#735) c31f6c3 flambda-backend: Fix treatment of functions called [@nontail] (ocaml#725) 847781e flambda-backend: Fix build_upstream post-PR703 (ocaml#712) bfcbbf8 flambda-backend: Extend Pblock value kind to handle variants (ocaml#703) b2cab95 flambda-backend: Merge ocaml-jst a6d6e0e flambda-backend: Merge ocaml-jst 88a4f63 flambda-backend: Use Pmakearray for immutable arrays (ocaml#699) eeaa44b flambda-backend: Install an ocamldoc binary (ocaml#695) 48d322b flambda-backend: Ensure that GC is not invoked from bounds check failures (ocaml#681) 4370fa1 flambda-backend: Review changes of term directory (ocaml#602) 65a4566 flambda-backend: Add code coverage using bisect_ppx (ocaml#352) 63ab65f flambda-backend: Bugfix for primitive inclusion (ocaml#662) 7e3e0c8 flambda-backend: Fix inclusion checks for primitives (ocaml#661) 96c68f9 flambda-backend: Speed up linking by changing cmxa format (ocaml#607) 1829150 flambda-backend: Bugfix for Translmod.all_idents (ocaml#659) git-subtree-dir: ocaml git-subtree-split: ce76e02
* Ood code uniformization: paper * Let metadata be the @@deriving yaml type * Let Paper.t be an alias of Paper.metadata * Misc required changes * Formatting Co-authored-by: Cuihtlauac ALVARADO <cuihtmlauac@tarides.com>
This PR is about allowing to compile with or without flambda independently of the default mode chosen at configure-time.
The configure-time option determines the default mode (and the one used to compiled stdlib and compiler-libs), but the restriction that code compiled with/without flambda (as determined at configure-time) cannot be linked together is lifted.
The same magic number is used in .cmx files for flambda and non-flambda mode. Previously, different magic numbers were used, which leads to potentially cryptic error messages when trying to mix the two modes.
When compiling a unit B which imports A.cmx, in different mode w.r.t. flambda, cross-module optimization information from A.cmx are ignored (just as if A.cmx had been obtained by -opaque). This also trigger a new warning 61 explaning the situation (instead of the above-mentioned error message).
In addition, this removes some code duplication between asmpackager.ml and compilenv.ml.
In the long term, if the non-flambda mode is maintained, one could hope to get more interoperability between the two modes, i.e. mapping cross-module info of one mode into the other one, in only one or both directions. But even if we never reach that point, this PR will give more visibility to flambda since it simplifies testing flambdalocally (e.g. to see if some kinds of optimizations -- not involving external modules -- are triggered). For quick testing, it is much simpler to pass "-flambda" than to rebuild a full OCaml configured with -flambda (which is rather slow).
There is also the case of very big and boring modules which takes a lot of time to compile even with -Oclassic, and for which performance is known to be completely irrelevant. For these cases, one could use -no-flambda to speed up compilation.
There remains a TODO in Clflags (to initialize inlining threshold), hence the WIP in the title.