Isaac Freund fe3aa4ccd0

stage2/wasm: do incremental compilation in-memory ...

Before this commit the wasm backend worked similarly to elf. As
functions were generated they were written directly to the output file
and existing code was shifted around in the file as necessary. This
approach had several disadvantages:

- Large amounts of padding in the output were necessary to avoid
expensive copying of data within the file.
- Function/type/global/etc indexes were required to be known at the time
of preforming codegen, which severely limited the flexibility of where
code could be placed in the binary
- Significant complexity to track the state of the output file through
incremental updates

This commit takes things in a different direction. Code is incrementally
compiled into in-memory buffers and the entire binary is rewritten using
these buffers on flush. This has several advantages:

- Significantly smaller resulting binaries
- More performant resulting binaries due to lack of indirection
- Significantly simpler compiler code
- Indexes no longer need to be known before codegen. We can track where
Decls must be referenced by index insert the proper indexes while
writing the code in the flush() function. This is not yet implemented
but is planned for the next commit.

The main disadvantage is of course increased memory usage in order to
store these buffers of generated code.

2020-08-19 02:05:01 +02:00

..

MachO.zig

stage2/wasm: write exports on flush, cleanup

2020-08-18 01:01:13 +02:00

Wasm.zig

stage2/wasm: do incremental compilation in-memory

2020-08-19 02:05:01 +02:00