Eliminate allocation of dummy function #1013
Conversation
| | List _a0 -> | ||
| let hsv = fold_int hsv 1 in | ||
| let hsv = hsv in hash_fold_list hash_fold_t hsv _a0 : state -> t -> state) | ||
| and (hash : t -> hash_value) = |
There was a problem hiding this comment.
I'm not seeing this function in the output. Did it get inlined?
There was a problem hiding this comment.
Could you add a test with functions where none of them get inlined?
There was a problem hiding this comment.
Note that the inlining was enabled by the last commit. Probably better the review per commits
There was a problem hiding this comment.
I've tune the test to prevent inlining
08bf14e to
8c1fc00
Compare
|
@xclerc, do you want to take a look at this one ? |
|
Just to be sure I understand the optimization: the idea is that every time we have It looks like this call to filter is expected to be the identity. My understanding is |
Correct
That sound correct. We should at least add some assertion. |
|
For the record, caml_alloc_dummy_function was introduced in 4.02.3 |
Looking more closely at the code, it's not the case. [filter] is here to only keep info from [caml_update_dummy] that have a corresponding [caml_alloc_dummy_function]. There are other cases (e.g. I've updated the code with comments. |
…ml-ppx, js_of_ocaml-lwt, js_of_ocaml-toplevel, js_of_ocaml-tyxml, js_of_ocaml and js_of_ocaml-ppx_deriving_json (3.7.0) CHANGES: ## Features/Changes * Runtime: allow one to override xmlHttpRequest.create (ocsigen/js_of_ocaml#1002) * Runtime: Change the semantic of MlBytes.toString, introduce MlBytes.toUtf16 * Compiler: initial support for OCaml 4.11 * Compiler: initial support for OCaml 4.12 * Compiler: improve the javascript parser by relying on menhir incremental api. * Compiler: Eliminate allocation of dummy function ocsigen/js_of_ocaml#1013 ## Bug fixes * Compiler: fix code generation for recursive function under for-loops (ocsigen/js_of_ocaml#1009) * Compiler: the jsoo compiler compiled to javascript was not behaving correctly when parsing constant in the from the bytecode * Compiler: make sure inline doesn't loop indefinitly (ocsigen/js_of_ocaml#1043) * Compiler: fix bug generating invalid javascript for if-then construct (ocsigen/js_of_ocaml#1046) * Compiler: do not use polymorphic comparison when joining float values (ocsigen/js_of_ocaml#1048) * Lib: Rename msg to message in Worker (ocsigen/js_of_ocaml#1037) * Lib: fix graphics_js when build with separate compilation (ocsigen/js_of_ocaml#1029)
…ml-ppx, js_of_ocaml-lwt, js_of_ocaml-toplevel, js_of_ocaml-tyxml, js_of_ocaml and js_of_ocaml-ppx_deriving_json (3.7.1)
CHANGES:
## Features/Changes
* lib: Add Navigator.{vendor,maxTouchPoints} (ocsigen/js_of_ocaml#1062)
* lib: adds the intersection observer API (ocsigen/js_of_ocaml#1063)
## Bug fixes
* compiler: revert of "Eliminate allocation of dummy function ocsigen/js_of_ocaml#1013"
* compiler: fix for ocsigen/js_of_ocaml#1051 (ocsigen/js_of_ocaml#1052), Ensure the overflow warning is always displayed
* runtime: add missing primitives for 4.11
* lib: Fix resize-observer (ocsigen/js_of_ocaml#1058)
The PR:
.funproperty proxy for functions.caml_alloc_dummy_function). The dummy allocation is not necessary in JavaScript due to the weird non-lexical scoping.Assuming the optimization properly eliminate all occurrences of
caml_alloc_dummy_function, we should be able to remove.funproperty handling from the runtime.Note that
caml_alloc_dummy_functionwas introduced in OCaml4.02.3, we would need to bump the lower bound from4.02.0to4.02.3which is fine.