| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
| |
Reland of #2864
Also ensure a relative install rpath by adding setup to each tool config.
The CMake code is cribbed from LLVM's implementation.
|
| |
|
| |
This reverts commit f6b7f0018ca5ce604e94cc6cf50ee712bb7e9b27.
|
| |
|
| |
When building the libbinaryen dynamic library, also link the binaryen tools against it. This reduces combined tool size on mac from 76M to 2.8M
|
| | |
|
| |
|
|
|
|
|
| |
Turned out that the behavior of MODULARIZE_INSTANCE, which has
been removed from Emscripten lately, cannot be easily reproduced
using MODULARIZE. So, instead of modularizing and attempting to
undo it, this just uses some good old wrapper code to achieve the same.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
CMAKE_PROJECT_VERSION is only predefined on cmake 3.12 and later,
so the previous code produced an empty version number which leads
to parsing errors when emcc checks the version.
Use of the older PROJECT_VERSION variable as the source of the
original version works here, as there's only one toplevel project
defined.
|
| | |
|
| |
|
|
|
|
|
|
| |
This can occurs in a shallow clone for example that doesn't have
any version tags in its history. This is happening on travis CI
which is causing the builds to fail since travis uses `--depth=50`
when it clones.
Fixes #2617
|
| |
|
|
|
| |
Binaryen.js now uses binaryen (was Binaryen) as its global
name to align with the npm package. Also fixes issues with
emitting and testing both the JS and Wasm builds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new version string looks like this:
wasm-opt version 90 (version_90-18-g77329439d)
The version reported here is the version from the CMakeLists.txt file
followed by the git version in brackets. We verify that the main
version here matches the CHANGELOG to prevent people from changing
one without changeing the other.
This will help with emscripten that wants to be able to programaticaly
check the --version of binaryen tools.
See https://github.com/emscripten-core/emscripten/issues/10175
|
| |
|
|
|
|
|
| |
Only use git to set version number if .git directory is present.
This means that for release archives the VERSION string will be used
as-is.
Fixes #2563
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR enables compiling Binaryen to WebAssembly when building binaryen.js. Since WebAssembly is best compiled and instantiated asynchronously in browsers, it also adds a new mechanism to tell if respectively when the module is ready by means of one of the following:
// Using a promise
const binaryen = require("binaryen");
binaryen.ready.then(() => {
... use normally ...
});
// Using await
const binaryen = require("binaryen");
(async () => {
await binaryen.ready;
... use normally ...
})();
// Where top-level await is available
const binaryen = await require("binaryen").ready;
... use normally ...
One can also tell if Binaryen is already ready (for example when assuming it in follow-up code) by:
if (/* we already know that */ binaryen.isReady) {
... use normally ...
} else {
throw Error("Binaryen is supposed to be ready here but isn't");
}
The JS test cases have been updated accordingly by wrapping everything in a test function and invoking it once ready. Documentation will have to be updated as well to cover this of course. New file size is about 2.5mb, even though the Wasm becomes inlined into the JS file which makes distribution across different environments a lot easier.
Also makes building binaryen (to either js or wasm) emit binaryen.js, and not binaryen_js.js etc.
Supersedes and thus fixes #1381
With .ready it also fixes #2452
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This imports LLVM code for DWARF handling. That code has the
Apache 2 license like us. It's also the same code used to
emit DWARF in the common toolchain, so it seems like a safe choice.
This adds two passes: --dwarfdump which runs the same code LLVM
runs for llvm-dwarfdump. This shows we can parse it ok, and will
be useful for debugging. And --dwarfupdate writes out the DWARF
sections (unchanged from what we read, so it just roundtrips - for
updating we need #2515).
This puts LLVM in thirdparty which is added here.
All the LLVM code is behind USE_LLVM_DWARF, which is on
by default, but off in JS for now, as it increases code size by 20%.
This current approach imports the LLVM files directly. This is not
how they are intended to be used, so it required a bunch of
local changes - more than I expected actually, for the platform-specific
stuff. For now this seems to work, so it may be good enough, but
in the long term we may want to switch to linking against libllvm.
A downside to doing that is that binaryen users would need to
have an LLVM build, and even in the waterfall builds we'd have a
problem - while we ship LLVM there anyhow, we constantly update
it, which means that binaryen would need to be on latest llvm all
the time too (which otherwise, given DWARF is quite stable, we
might not need to constantly update).
An even larger issue is that as I did this work I learned about how
DWARF works in LLVM, and while the reading code is easy to
reuse, the writing code is trickier. The main code path is heavily
integrated with the MC layer, which we don't have - we might want
to create a "fake MC layer" for that, but it sounds hard. Instead,
there is the YAML path which is used mostly for testing, and which
can convert DWARF to and from YAML and from binary. Using
the non-YAML parts there, we can convert binary DWARF to
the YAML layer's nice Info data, then convert that to binary. This
works, however, this is not the path LLVM uses normally, and it
supports only some basic DWARF sections - I had to add ranges
support, in fact. So if we need more complex things, we may end
up needing to use the MC layer approach, or consider some other
DWARF library. However, hopefully that should not affect the core
binaryen code which just calls a library for DWARF stuff.
Helps #2400
|
| | |
|
| |
|
|
| |
debug builds. (#2507)
|
| |
|
|
|
|
|
|
| |
We always enable assertions by default, but this options allows for
a build without them.
Fix all errors in the ASSERTIONS=OFF build, even though we don't
normally build this its good to keep it building.
|
| |
|
| |
This is line with modern cmake conventions is much less SHOUTY!
|
| |
|
|
|
|
|
|
| |
With #2483 merged, emcc hits the following warning when attempting to compile wasm-opt to JS with Emsdk:latest-fastcomp:
shared:WARNING: for wasm there is no need to set ELIMINATE_DUPLICATE_FUNCTIONS, the binaryen optimizer does it automatically
shared:ERROR: treating warnings as errors (-Werror)
Appears this happens because ELIMINATE_DUPLICATE_FUNCTIONS is set for all targets when using fastcomp, even though only binaryen_js uses WASM=0. So this PR moves it into the binaryen_js target.
|
| |
|
| |
And use LTO in upstream opt builds, which improves code size by >20%.
|
| | |
|
| |
|
|
|
|
|
|
| |
Fixes #2453
As a bonus this also provides a port of wasm-opt etc. with NODERAWFS
and everything seems to work, that is, you can run stuff like
nodejs wasm-opt.js input.wasm --metrics
|
| |
|
|
|
|
|
|
|
| |
using the `$<TARGET_OBJECTS:objlib>` syntax. Use this variable when
adding `libbinaryen` as static or shared library. Additionally, use the
variable with the object files to simplify the `TARGET_LINK_LIBRARIES`
commands: add the object libraries to the sources of executables and
drop the use of our libraries in `TARGET_LINK_LIBRARIES`. (Object
libraries cannot be linked but must be used as sources. See
https://cmake.org/pipermail/cmake/2018-June/067721.html)
|
| |
|
|
|
| |
(#2474)
This reverts commit bf8f36c31c0b8e6213bce840be66937dd6d0f6af.
|
| |
|
|
|
|
|
|
|
| |
This is the start of a larger refactoring to remove FunctionType entirely and
store types and signatures directly on the entities that use them. This PR
updates BrOnExn and Events to remove their use of FunctionType and makes the
BinaryWriter traverse the module and collect types rather than using the global
FunctionType list. While we are collecting types, we also sort them by frequency
as an optimization. Remaining uses of FunctionType in Function, CallIndirect,
and parsing will be removed in a future PR.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Transform libraries created in subdirectories from statically linked
libraries to CMake object libraries.
* Link object libraries as `PRIVATE` to `libbinaryen`.
According to CMake documentation: "Libraries and targets following
PRIVATE are linked to, but are not made part of the link interface."
This is exactly what we want, as we only want the C API to be part of
the interface.
|
| |
|
|
|
|
| |
Since the waterfall's CMake was too old to target C++17 and many LTS
systems may not yet support C++17. Also updates the minimum required
CMake version to one that mentions the CXX_STANDARD variable in its
docs.
|
| |
|
|
|
|
| |
Adds support for the new load and extend instructions. Also updates
from C++11 to C++17 in order to use generic lambdas in the interpreter
implementation.
|
| |
|
|
|
| |
On Windows, symbols have to be explicitly exported to make them visible/accessible in a shared library. Binaryen.dll currently doesn't export any symbols as a result.
Marking all exported methods as `BINARYEN_API` that is defined as `__declspec(dllexport)` on Windows, unless building a static library.
|
| |
|
|
|
| |
See #2314
|
| | |
|
| |
|
| |
Oversight from #2105
|
| |
|
|
|
|
|
|
|
|
|
| |
Update build-js.sh to output to `out` directory. This is district
from the `bin` directory which is used by the cmake build and may or
may not live in the source tree. The `out` directory currently always
lives in the source tree.
As a followup change I hope to additionally move all test outout into
this tree.
See #2104
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
