Remove unused separate_asm.py and emlink.py tools

These are no longer used or usefull since fastcomp
removal.

See: #11860

Author: sbc100

docs/emcc.txt

@@ -585,12 +585,6 @@ Options that are modified or new in *emcc* are listed below:
    with other bitcode files), instead of compiling all the way to
    JavaScript.
 
-"--separate-asm"
-   Emits asm.js in one file, and the rest of the code in another, and
-   emits HTML that loads the asm.js first, in order to reduce memory
-   load during startup. See Avoid memory spikes by separating out
-   asm.js.
-
 "--output_eol windows|linux"
    Specifies the line ending to generate for the text files that are
    outputted. If "--output_eol windows" is passed, the final output

emlink.py

@@ -84,7 +84,6 @@ Emscripten compiler output often consists of several files and not just one. The
  - `emcc ... -o output.bc` does not produce a final asm.js/wasm build, but stops at LLVM bitcode generation stage, and produces a single LLVM bitcode file `output.bc`. Likewise only one bitcode file is produced if output suffix is `.ll`, `.o`, '.obj', '.lo', `.lib`, `.dylib` or `.so`.
  - `emcc ... -o output.a` generates a single archive file `output.a`.
  - `emcc ... -o output.{html,js} -s WASM=0` causes the compiler to target asm.js, and therefore a `.wasm` file is not produced.
- - `emcc ... -o output.{html,js} -s WASM=0 --separate-asm` likewise targets asm.js, but splits up the generated code to two files, `output.js` and `output.asm.js`.
  - `emcc ... -o output.{html,js} --emit-symbol-map` produces a file `output.{html,js}.symbols` if WebAssembly is being targeted (`-s WASM=0` not specified), or if asm.js is being targeted and `-Os`, `-Oz` or `-O2` or higher is specified, but debug level setting is `-g1` or lower (i.e. if symbols minification did occur).
  - `emcc ... -o output.{html,js} -s WASM=0 --memory-init-file 1` causes the generation of `output.{html,js}.mem` memory initializer file. Pasing `-O2`, `-Os` or `-Oz` also implies `--memory-init-file 1`.
  - `emcc ... -o output.{html,js} -g4` generates a source map file `output.wasm.map`. If targeting asm.js with `-s WASM=0`, the filename is `output.{html,js}.map`.

site/source/docs/compiling/Building-Projects.rst

@@ -11,8 +11,6 @@ Build Files and Custom Shell
 
 Emscripten build output consists of two essential parts: 1) the low level compiled code module and 2) the JavaScript runtime to interact with it. If targeting WebAssembly which is done with linker flags ``-s WASM=1 -o out.html``, the compiled code is stored in a file ``out.wasm`` and the runtime lives in a file ``out.js``. When targeting asm.js there exists an additional binary file ``out.mem`` that contains the static memory section of the compiled code. This part is embedded in the ``out.wasm`` file when targeting WebAssembly.
 
-By default when targeting asm.js, the compiled code and the runtime are fused in the same ``out.js`` file. For moderately large asm.js projects, it is recommended to use the ``--separate-asm`` flag to separate the compiled code to its own ``out.asm.js`` file, which enables browsers to optimize memory usage for the compiled asm.js code.
-
 Additional build output files can also exist, depending on which features are used. If the Emscripten file packager is used, a binary ``out.data`` package is generated, along with an associated ``out.data.js`` loader file. Also Emscripten pthreads and Fetch APIs have their own associated Web Worker related script ``.js`` output files.
 
 Developers can choose to output either to JavaScript or HTML. If outputting JavaScript (``emcc -o out.js``), the developer is expected to manually create the ``out.html`` main page in which the code is run in browsers. When targeting HTML with ``emcc -o out.html`` (the recommended build mode), Emscripten will generate the HTML shell file automatically. This shell file can be customized by using the ``emcc -o out.html --shell-file path/to/custom_shell.html`` linker directive. Copy the `default minimal HTML shell file <https://github.com/emscripten-core/emscripten/blob/master/src/shell_minimal.html>`_ from Emscripten repository to your project tree to get a good starting template for a customized shell file.

site/source/docs/compiling/Deploying-Pages.rst

@@ -103,31 +103,6 @@ Very large codebases
 
 The previous section on reducing code size can be helpful on very large codebases. In addition, here are some other topics that might be useful.
 
-.. _optimizing-code-separating_asm:
-
-Avoid memory spikes by separating out asm.js
---------------------------------------------
-
-When emitting asm.js, by default Emscripten emits one JS file, containing the entire codebase: Both the asm.js code that was compiled, and the general code that sets up the environment, connects to browser APIs, etc. in a very large codebase, this can be inefficient in terms of memory usage, as having all of that in one script means the JS engine might use some memory to parse and compile the asm.js, and might not free it before starting to run the codebase. And in a large game, starting to run the code might allocate a large typed array for memory, so you might see a "spike" of memory, after which temporary compilation memory will be freed. And if big enough, that spike can cause the browser to run out of memory and fail to load the application. This is a known problem on `Chrome <https://code.google.com/p/v8/issues/detail?id=4392>`_ (other browsers do not seem to have this issue).
-
-A workaround is to separate out the asm.js into another file, and to make sure that the browser has a turn of the event loop between compiling the asm.js module and starting to run the application. This can be achieved by running **emcc** with ``--separate-asm``.
-
-You can also do this manually, as follows:
-
- * Run ``tools/separate_asm.py``. This receives as inputs the filename of the full project, and two filenames to emit: the asm.js file and a file for everything else.
- * Load the asm.js script first, then after a turn of the event loop, the other one, for example using code like this in your HTML file: ::
-
-    var script = document.createElement('script');
-    script.src = "the_asm.js";
-    script.onload = function() {
-      setTimeout(function() {
-        var script = document.createElement('script');
-        script.src = "the_rest.js";
-        document.body.appendChild(script);
-      }, 1); // delaying even 1ms is enough
-    };
-    document.body.appendChild(script);
-
 Running by itself
 -----------------
 

site/source/docs/optimizing/Optimizing-Code.rst

@@ -451,9 +451,6 @@ Options that are modified or new in *emcc* are listed below:
 ``-c``
   Tells *emcc* to generate LLVM bitcode (which can then be linked with other bitcode files), instead of compiling all the way to JavaScript.
 
-``--separate-asm``
-  Emits asm.js in one file, and the rest of the code in another, and emits HTML that loads the asm.js first, in order to reduce memory load during startup. See :ref:`optimizing-code-separating_asm`.
-
 ``--output_eol windows|linux``
   Specifies the line ending to generate for the text files that are outputted. If "--output_eol windows" is passed, the final output files will have Windows \r\n line endings in them. With "--output_eol linux", the final generated files will be written with Unix \n line endings.
 

site/source/docs/tools_reference/emcc.rst

@@ -823,7 +823,7 @@ var SHELL_FILE = 0;
 var RELOCATABLE = 0;
 
 // A main module is a file compiled in a way that allows us to link it to
-// a side module using emlink.py.
+// a side module at runtime.
 //  1: Normal main module.
 //  2: DCE'd main module. We eliminate dead code normally. If a side
 //     module needs something from main, it is up to you to make sure

src/settings.js

@@ -1555,9 +1555,6 @@ def btest(self, filename, expected=None, reference=None, force_c=False,
     filename_is_src = '\n' in filename
     src = filename if filename_is_src else ''
     original_args = args[:]
-    if 'WASM=0' not in args:
-      # Filter out separate-asm, which is implied by wasm
-      args = [a for a in args if a != '--separate-asm']
     # add in support for reporting results. this adds as an include a header so testcases can
     # use REPORT_RESULT, and also adds a cpp file to be compiled alongside the testcase, which
     # contains the implementation of REPORT_RESULT (we can't just include that implementation in

tests/runner.py

@@ -6725,15 +6725,11 @@ def test_disable_inlining(self):
     syms = building.llvm_nm('test2.bc', include_internal=True)
     assert 'foo' in syms.defs, 'foo() should not be inlined'
 
-  @no_wasm_backend('--separate-asm')
   def test_output_eol(self):
-    # --separate-asm only makes sense without wasm (no asm.js with wasm)
-    for params in [[], ['--separate-asm', '-s', 'WASM=0'], ['--proxy-to-worker'], ['--proxy-to-worker', '--separate-asm', '-s', 'WASM=0']]:
+    for params in [[], ['--proxy-to-worker'], ['--proxy-to-worker', '-s', 'WASM=0']]:
       for output_suffix in ['html', 'js']:
         for eol in ['windows', 'linux']:
           files = ['a.js']
-          if '--separate-asm' in params:
-            files += ['a.asm.js']
           if output_suffix == 'html':
             files += ['a.html']
           cmd = [EMCC, path_from_root('tests', 'hello_world.c'), '-o', 'a.' + output_suffix, '--output_eol', eol] + params
@@ -6792,37 +6788,6 @@ def test_binaryen_warn_mem(self):
     self.run_process([EMCC, path_from_root('tests', 'hello_world.cpp'), '-s', 'INITIAL_MEMORY=' + str(16 * 1024 * 1024), '--pre-js', 'pre.js', '-s', 'ALLOW_MEMORY_GROWTH=1', '-s', 'WASM_ASYNC_COMPILATION=0'])
     self.assertContained('hello, world!', self.run_js('a.out.js'))
 
-  @no_wasm_backend('asm.js specific')
-  def test_binaryen_asmjs_outputs(self):
-    # Test that an .asm.js file is outputted exactly when it is requested.
-    for args, output_asmjs in [
-      ([], False),
-      (['-s', 'MAIN_MODULE=2'], False),
-    ]:
-      with temp_directory(self.get_dir()) as temp_dir:
-        cmd = [EMCC, path_from_root('tests', 'hello_world.c'), '-o', os.path.join(temp_dir, 'a.js')] + args
-        print(' '.join(cmd))
-        self.run_process(cmd)
-        if output_asmjs:
-          self.assertExists(os.path.join(temp_dir, 'a.asm.js'))
-        self.assertNotExists(os.path.join(temp_dir, 'a.temp.asm.js'))
-
-    # Test that outputting to .wasm does not nuke an existing .asm.js file, if
-    # user wants to manually dual-deploy both to same directory.
-    with temp_directory(self.get_dir()) as temp_dir:
-      cmd = [EMCC, path_from_root('tests', 'hello_world.c'), '-s', 'WASM=0', '-o', os.path.join(temp_dir, 'a.js'), '--separate-asm']
-      print(' '.join(cmd))
-      self.run_process(cmd)
-      self.assertExists(os.path.join(temp_dir, 'a.asm.js'))
-
-      cmd = [EMCC, path_from_root('tests', 'hello_world.c'), '-o', os.path.join(temp_dir, 'a.js')]
-      print(' '.join(cmd))
-      self.run_process(cmd)
-      self.assertExists(os.path.join(temp_dir, 'a.asm.js'))
-      self.assertExists(os.path.join(temp_dir, 'a.wasm'))
-
-      self.assertNotExists(os.path.join(temp_dir, 'a.temp.asm.js'))
-
   def test_binaryen_mem(self):
     for args, expect_initial, expect_max in [
         (['-s', 'INITIAL_MEMORY=20971520'], 320, 320),

tests/test_other.py

@@ -53,7 +53,6 @@
 
 # warning about absolute-paths is disabled by default, and not enabled by -Wall
 diagnostics.add_warning('absolute-paths', enabled=False, part_of_all=False)
-diagnostics.add_warning('separate-asm')
 diagnostics.add_warning('almost-asm')
 diagnostics.add_warning('invalid-input')
 # Don't show legacy settings warnings by default