| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This commit tweaks the AppVeyor configuration to publish 64 and 32-bit
artifacts as part of the normal release builds. Configuration was also
added to be sure to compile code with `/MT` on MSVC to ensure that the
released artifacts depend on as few DLLs as possible, hopefully making
them as portable as possible.
cc #1695
|
|
|
| |
It is not very useful.
|
|\
| |
| | |
Fix Visual Studio 2017 15.8 build
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
The error in #1845 shows:
/<<PKGBUILDDIR>>/src/mixed_arena.h: In member function 'void* MixedArena::allocSpace(size_t, size_t)':
/<<PKGBUILDDIR>>/src/mixed_arena.h:125:43: error: 'new' of type 'MixedArena::Chunk' {aka 'std::aligned_storage<32768, 16>::type'} with extended alignment 16 [-Werror=aligned-new=]
chunks.push_back(new Chunk[numChunks]);
^
/<<PKGBUILDDIR>>/src/mixed_arena.h:125:43: note: uses 'void* operator new [](std::size_t)', which does not have an alignment parameter
/<<PKGBUILDDIR>>/src/mixed_arena.h:125:43: note: use '-faligned-new' to enable C++17 over-aligned new support
It turns out I had misread the aligned_storage docs, and they don't actually do what we need, which is a convenient cross-platform way to do aligned allocation, since new itself doesn't support that. Sadly it seems there is no cross-platform way to do it right now, so I added a header in support which abstracts over the windows and everything-else ways.
Also add some ctest testing, which runs on windows, so we get basic windows coverage in our CI.
|
|
|
|
|
|
| |
Where reasonable from a readability perspective, remove default cases
in switches over types and instructions. This makes future feature
additions easier by making the compiler complain about each location
where new types and instructions are not yet handled.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Rename the `wasm2asm` tool to `wasm2js`
This commit performs a relatively simple rename of the `wasm2asm` tool to
`wasm2js`. The functionality of the tool doesn't change just yet but it's
intended that we'll start generating an ES module instead of just an `asm.js`
function soon.
* wasm2js: Support `*.wasm` input files
Previously `wasm2js` only supported `*.wast` files but to make it a bit easier
to use in tooling pipelines this commit adds support for reading in a `*.wasm`
file directly. Determining which parser to use depends on the input filename,
where the binary parser is used with `*.wasm` files and the wast parser is used
for all other files.
* wasm2js: Emit ESM imports/exports by default
This commit alters the default behavior of `wasm2js` to emit an ESM by default,
either importing items from the environment or exporting. Items like
initialization of memory are also handled here.
|
|
|
|
| |
add_subdirectory(binaryen) (#1637)
|
| |
|
|
|
|
|
|
|
| |
Instead, we point users to the bot @dcodeIO has, see #1571
This is useful because otherwise every change to binaryen.js requires bundling a build here, which is more work for contributors (and also grows the git repo over time).
We still keep a bundled build of wasm.js. We use that for testing of the interpreter currently, and emscripten depends on it. Eventually wasm2asm may replace that. In any case, wasm.js builds are required far less frequently than binaryen.js.
|
|
|
|
| |
s2wasm is no longer used my emscripten and as far as I know now
as no other users.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a pass that implements "function pointer cast emulation" - allows indirect calls to go through even if the number of arguments or their types is incorrect. That is undefined behavior in C/C++ but in practice somehow works in native archs. It is even relied upon in e.g. Python.
Emscripten already has such emulation for asm.js, which also worked for asm2wasm. This implements something like it in binaryen which also allows the wasm backend to use it. As a result, Python should now be portable using the wasm backend.
The mechanism used for the emulation is to make all indirect calls use a fixed number of arguments, all of type i64, and a return type of also i64. Thunks are then placed in the table which translate the arguments properly for the target, basically by reinterpreting to i64 and back. As a result, receiving an i64 when an i32 is sent will have the upper bits all zero, and the reverse would truncate the upper bits, etc. (Note that this is different than emscripten's existing emulation, which converts (as signed) to a double. That makes sense for JS where double's can contain all numeric values, but in wasm we have i64s. Also, bitwise conversion may be more like what native archs do anyhow. It is enough for Python.)
Also adds validation for a function's type matching the function's actual params and result (surprised we didn't have that before, but we didn't, and there was even a place in the test suite where that was wrong).
Also simplifies the build script by moving two cpp files into the wasm/ subdir, so they can be built once and shared between the various tools.
|
|
|
| |
`-Werror` and the warnings provided by any specific toolchain/compiler are not standard.
|
|
|
|
|
|
|
|
|
|
| |
* refactor BINARYEN_PASS_DEBUG code for writing byn-* files, make it easy to emit binaries instead of text
* fix up bad argument numbers in asm2wasm. This can be caused by undefined behavior on the LLVM side, which happens to work natively. it's nicer to fix it up like it would be in a native build, and give a warning, instead of failing to compile
* update build-js.sh
* updated builds
|
| |
|
| |
|
|
|
|
|
|
|
| |
* wasm-link-metadata: Use `__data_end` symbol.
* Add --global-base param to emscripten-wasm-finalize to compute staticBump properly
* Let ModuleWriter write to a provided Output object
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* fix unused variable warnings in wasm2asm.cpp
No need to give the bad_alloc exception a name when we do nothing with it.
* add appropriate casts for shift operands
MSVC complains about implicitly converting results from 32 bits to 64
bits here, so we might as well make it clear that we intended the 64-bit
shift to happen in the first place.
* disable C4722 on MSVC
We annotated Fatal::~Fatal with WASM_NORETURN, yet MSVC still warns, so
take the next step and silence the warning completely.
* don't warn about "deprecated" POSIX functions with MSVC
Non-Windows platforms don't have the names MSVC recommends using, and
everybody understands the POSIX names, so just silence the warning.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Skeleton of a beginning of o2wasm, WIP and probably not going to be used
* Get building post-cherry-pick
* ast->ir, remove commented out code, include a debug module print because linking
* Read linking section, print emscripten metadata json
* WasmBinaryWriter emits user sections on Module
* Remove debugging prints, everything that isn't needed to build metadata
* Rename o2wasm to lld-metadata
* lld-metadata support for outputting to file
* Use tables index instead of function index for initializer functions
* Add lld-emscripten tool to add emscripten-runtime functions to wasm modules (built with lld)
* Handle EM_ASM in lld-emscripten
* Add a list of functions to forcibly export (for initializer functions)
* Disable incorrect initializer function reading
* Add error printing when parsing .o files in lld-metadata
* Remove ';; METADATA: ' prefix from lld-metadata, output is now standalone json
* Support em_asm consts that aren't at the start of a segment
* Initial test framework for lld-metadata tool
* Add em_asm test
* Add support for WASM_INIT_FUNCS in the linking section
* Remove reloc section parsing because it's unused
* lld-emscripten can read and write text
* Add test harness for lld-emscripten
* Export all functions for now
* Add missing lld test output
* Add support for reading object files differently
Only difference so far is in importing mutable globals being an object
file representation for symbols, but invalid wasm.
* Update help strings
* Update linking tests for stackAlloc fix
* Rename lld-emscripten,lld-metadata to wasm-emscripten-finalize,wasm-link-metadata
* Add help text to header comments
* auto& instead of auto &
* Extract LinkType to abi/wasm-object.h
* Remove special handling for wasm object file reading, allow mutable globals
* Add braces around default switch case
* Fix flake8 errors
* Handle generating dyncall thunks for imports as well
* Use explicit bool for stackPointerGlobal
* Use glob patterns for lld file iteration
* Use __wasm_call_ctors for all initializer functions
|
|
|
|
|
|
|
| |
This adds a new tool for better dead code elimination. The problem this helps overcome is when the wasm module is part of something larger, like a wasm+JS combination, and therefore doing DCE in either one is not sufficient as it can't remove a cycle spanning the wasm and JS worlds. Concretely, when binaryen performs DCE by itself, it can never remove an export, because it considers those roots - but in the larger ("meta") space outside, they may actually be removable.
To solve that, this tool receives a description of the outside graph (in very abstract form), including which nodes are roots. It then adds to that graph nodes from the wasm, so that we have a single graph representing the entire space (the outside + wasm + connections between them). It then performs DCE, finding what is not reachable from the roots, and cleaning it up from the wasm. It of course can't clean up things from the outside, since all it has is the abstract representation of those things in the graph, but it prints out the ids of the removable nodes, which an outside tool can use.
This tool is written in as general a way as possible, hopefully it can have multiple uses. The use I have in mind is to write something in emscripten that uses this to DCE the JS+wasm combination that we emit.
|
| |
|
| |
|
|
|
| |
The IR is indeed a tree, but not an "abstract syntax tree" since there is no language for which it is the syntax (except in the most trivial and meaningless sense).
|
|
|
|
|
|
|
| |
This makes wasm validation parallel (the function part). This makes loading+validating tanks (a 12MB wasm file) 2.3x faster on a 4-core machine (from 3.5 to 1.5 seconds). It's a big speedup because most of loading+validating was actually validating.
It's also noticeable during compilation, since we validate by default at the end. 8% faster on -O2 and 23% on -O0. So actually fairly significant on -O0 builds.
As a bonus, this PR also moves the code from being 99% in the header to be 1% in the header.
|
|
|
| |
Reduce an interesting wasm to a smaller still interesting wasm. This takes an arbitrary command to run, and reduces the wasm as much as it can while keeping the behavior of that command fixed. This can be used to reduce compiler bugs in an arbitrary VM, etc.
|
|
|
|
| |
* Added BinaryenModulePrintAsmjs (using wasm2asm) + Module#emitAsmjs JS binding
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Get wasm2asm building again
Updates CMakeLists.txt to have wasm2asm built by default, updates
wasm2asm.h to account for recent interface changes, and restores
JSPrinter functionality.
* Implement splice for array values
* Clean up wasm2asm testing
* Print semicolons after statements in blocks
* Cleanups and semicolons for condition arms
* Prettify semicolon emission
|
| |
|
|
|
| |
Also small cleanup to CMake libraries
|
|
|
|
|
| |
I noticed that when settings -DCMAKE_C_COMPILER=clang I was
getting a cmake warning when building dummy.c:
error: invalid argument '-std=c++11' not allowed with 'C/ObjC'
|
| |
|
|
|
|
|
| |
This adds a pass that converts to a CFG, runs the relooper, and re-generates wasm from that. This depends on flatten-control-flow being run before.
The main goal here is to help code generators other than asm2wasm (which already receives relooped code from fastcomp).
|
|
|
|
|
| |
Add wasm-ctor-eval, which evaluates functions at compile time - typically static constructor functions - and applies their effects into memory, saving work at startup. If we encounter something we can't evaluate at compile time in our interpreter, stop there.
This is similar to ctor_evaller.py in emscripten (which was for asm.js).
|
|
|
|
|
|
| |
* Fixed issue 965 as per @binji's wabt fix, add platform-specific build options, which fixes building on ARM.
* Added logging for platform-specific flags
|
|
|
|
| |
wasm-merge tool: combines two wasm files into a larger one, handling collisions, and aware of the dynamic linking conventions. it does not do full static linking, but may eventually.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix install locations per FHS and allow to customize them
Include built-in cmake module GNUInstallDirs that defines customizable
CMAKE_INSTALL_* variables with common defaults per FHS.
New FS structure when installed with `CMAKE_INSTALL_PREFIX=/usr`,
`BUILD_SHARED_LIBS=ON`:
usr
├── bin
│ ├── asm2wasm
│ ├── s2wasm
│ ├── wasm-as
│ ├── wasm-dis
│ ├── wasm-opt
│ └── wasm-shell
├── include
│ └── binaryen-c.h
├── lib64
│ └── libbinaryen.so
└── share
│ └── binaryen
│ ├── binaryen.js
│ └── wasm.js
└── src
└── js
├── binaryen.idl
├── binaryen.js-extended.js
├── binaryen.js-post.js
└── binaryen.js-pre.js
See https://cmake.org/cmake/help/v2.8.7/cmake.html#module:GNUInstallDirs
for more information about used variables.
Fixes #951
|
|
|
|
|
|
| |
* fix asm2wasm stack-overflow on windows
* set stack size to 8mb for consistency with Linux/Mac
|
|
|
|
| |
Split ExpressionAnalyzer and ExpressionManipulator into cpp files, and turn their giant template functions into simple functions which take a callback.
More organization, fewer mammoth headers, makes the build a few seconds faster, and the binaries a couple MB smaller.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The posix build enables assertions on release builds with
ADD_NONDEBUG_COMPILE_FLAG("-UNDEBUG")
but the windows build does not. This PR adds /UNDEBUG to the release
build flags but has the additional complication that /DNDEBUG is added
to CFLAGS by CMake by default, and MSVC will warn about having /UFOO
after /DFOO on the command line. So we scrub DNDEBUG from CFLAGS
as well.
Additional windows build cleanups:
Disable conversion/truncation warnings
Canonicalize flag style to use slashes everywhere instead of mixing
MSVC uses /Od (not /O0) to disable optimization
|
|
|
|
|
|
| |
This creates install rules for the binaryen shlib and the C header, as
well as for the various JS files (wasm.js and binaryen.js, as well as
those used by emscripten). It recreates in the install target the
current layout used by an in-tree build.
|
|
|
|
|
| |
Also moves the bulk of the code in wasm-s-parser into a cpp file.
Allows namespace and #include cleanups, and improves j4 compile time by 20%.
Should also make any future parser changes easier and more localized.
|
|
|
|
|
|
|
|
|
|
|
| |
* Minor improvements to the wasm-interpreter debug messages
1. Indent nested blocks for more readable structure (with numeric labels
to make it even clearer)
2. Print the names of the variables used for NOTE_EVALs
3. Print the values of arguments when entering a function call
* Move Indenter class to wasm-interpreter.cpp
|
|
|
|
| |
static analyzer during build. (#786)
|
|
|
|
| |
configuration time. This allows doing other types of builds than Debug or Release and fixes multigenerators such as Visual Studio or Xcode. (#764)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add a flag to s2wasm to export grow_memory
Binaryen's wasm.js-post.js calls back in to wasm in order to grow the
linear memory, via a function that asm2wasm exports called
__growWasmMemory.
This changes exposes that method through s2wasm when invoked with a
flag.
* Move AsmConstWalker from wasm-linker to wasm-emscripten
* Add test for memory growth in s2wasm
* Move makeDynCallThunks into wasm-emscripten module
* Move mutation in getTableSegment into a separate method
* Move emscripten metadata generation into wasm-emscripten
Also make AsmConstWalker internal to the wasm-emscripten module, as it's only used for the metadata pass.
|
|
|
|
| |
tests
|
| |
|
|
|
|
|
| |
* Added jobs for MinGW (64 bit) and MSVC (32 and 64 bits) with Release
configurations as well as MSVC (64 bit) with Debug configuration.
* Added badge to README.
|