| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
Turning it off removes the build dependency on the third-party googletest
library.
|
| |
|
|
|
|
|
| |
* use [[noreturn]] available since C++11 instead of compiler-specific attributes
* replace deprecated std::is_pod with is_trivial&&is_standard_layout (also available since C++11/14)
* explicitly capture this in [=] lambdas
* extra const functions in FeatureSet, fix implicit cast warning by using the features field directly
* Use CMAKE_CXX_STANDARD to ensure the C++ standard parameter is set on all targets, remove manual compiler flag workaround.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add gtest as a git submodule in third_party and integrate it into the build the
same way WABT does. Adds a new executable, `binaryen-unittests`, to execute
`gtest_main`. As a nontrivial example test, port one of the `TypeBuilder` tests
from example/ to gtest/.
Using gtest has a number of advantages over the current example tests:
- Tests are compiled and linked at build time rather than runtime, surfacing
errors earlier and speeding up test execution.
- Tests are all built into a single binary, reducing overall link time and
further reducing test overhead.
- Tests are built from the same CMake project as the rest of Binaryen, so
compiler settings (e.g. sanitizers) are applied uniformly rather than having
to be separately set via the COMPILER_FLAGS environment variable.
- Using the industry-standard gtest rather than our own script reduces our
maintenance burden.
Using gtest will lower the barrier to writing C++ tests and will hopefully lead
to us having more proper unit tests.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Previously Emscripten used -Oz. That does reduce code size, but it
turns out to make binaryen.js significantly slower (3x or more) than it
could be, which seems like the wrong tradeoff.
Fixes #4359
|
| | |
|
| |
|
|
| |
This version represents that current reality although we
would like to lower this for increased compatibility. See: #4299
|
| | |
|
| |
|
| |
This sets the C++ standard variable in the build to C++17, and makes use of std::optional (a C++17 library feature) in one place, to test that it's working.
|
| | |
|
| |
|
|
| |
The thinLTO backend is already multithreaded, so combining with
build system-level parallelism can bog a machine down.
|
| | |
|
| |
|
|
|
| |
As wasm-split has gained new functionality, its implementation file has become
large. In preparation for adding even more functionality, split the existing
implementation across multiple files in a new tools/wasm-split subdirectory.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, ref.func instructions would be assigned the canonical (i.e. first
parsed) heap type for the referenced function signature rather than the HeapType
actually specified in the type definition. In nominal mode, this could cause
validation failures because the types assigned to ref.func instructions would
not be correct.
Fix the problem by tracking function HeapTypes rather than function Signatures
when parsing the text format.
There can still be validation failures when round-tripping modules because
function HeapTypes are not properly preserved after parsing, but that will be
addressed in a follow-up PR.
|
| |
|
|
|
|
|
|
|
|
|
| |
These files are special in that they use define symbols that are not
defined within those files or other files included in those files; they
are supposed to be defined in source files that include these headers.
This has caused clang-tidy to fail every time these files have changed
because they are not compilable per se.
This PR solves the problem by changing their extension to `def`, which
is also used in LLVM codebase. LLVM has dozens of files like this whose
extension is `def`, which makes these not checked by clang-tidy.
|
| | |
|
| |
|
|
|
|
|
| |
This option will avoid installing the static library and headers, for
distributions that want to be as small as possible, and don't need
to support development with libbinaryen (such as emsdk).
It still installs the dynamic library since that's needed by the
tools.
|
| |
|
| |
Fixes: #3459
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This was originally landed as part of #3484 but this broke the emsdk CI
because we build binaryen on bionic there which is stuck on 3.10.2:
https://packages.ubuntu.com/bionic/cmake
We do use `add_link_options` but only when EMSCRIPTEN is defined which
doesn't effect normal desktop builds.
|
| |
|
| |
Followup on original conversion done in #2495.
|
| |
|
| |
Also adjust the check for Clang to also match AppleClang
|
| |
|
|
|
| |
Supports Clang, on win/mac/linux. Uses lld on Linux and Windows.
I haven't tested yet on Mac, but in theory it should work.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This uses the same technique used in llvm-lit to enable
running on in-tree tests with out-of-tree builds.
So you can run something like this:
../binaryen-out/bin/binaryen-lit test/lit/
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Implement an initial version of the wasm-split tool, which splits modules into a
primary module and a secondary module that can be instantiated after the primary
module. Eventually, this tool will be able to not only split modules, but also
instrument modules to collect profiles that will be able to guide later
splitting. In this initial version, however, wasm-split can neither perform
instrumentation nor consume any kind of profile data.
Despite those shortcomings, this initial version of the tool is already able to
perform module splitting according to function lists manually provided by the
user via the command line. Follow-up PRs will implement the stubbed out
instrumentation and profile consumption functionality.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lit and FileCheck are the tools used to run the majority of tests in LLVM. Each
lit test file contains the commands to be run for that test, so lit tests are
much more flexible and can be more precise than our current ad hoc testing
system. FileCheck reads expected test output from comments, so it allows test
output to be written alongside and interspersed with test input, making tests
more readable and precise than in our current system.
This PR adds a new suite to check.py that runs lit tests in the test/lit
directory. A few tests have been ported to demonstrate the features of the new
test runner.
This change is motivated by a need for greater flexibility in testing wasm-split.
See #3359.
|
| |
|
|
|
| |
Don't hardcode `lib`, it's incorrect for many systems (e.g. `lib64` is
common on some x86_64 distros like openSUSE). Use CMAKE_INSTALL_LIBDIR
instead.
|
| |
|
|
| |
- Add a MinGW CI build
- Add compiler flag to successfully build on MinGW
|
| |
|
| |
This improves binary size, for example shrinking binaryen.dylib on MacOS by half a megabyte.
|
| | |
|
| |
|
| |
The emscripten bug has been fixed in emscripten-core/emscripten#12329
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This PR contains:
- Changes that enable/disable tests on Windows to allow for better local testing.
- Also changes many abort() into Fatal() when it is really just exiting on error. This is because abort() generates a dialog window on Windows which is not great in automated scripts.
- Improvements to CMake to better work with the project in IDEs (VS).
|
| | |
|
| |
|
|
|
| |
Switch us back to C++ standard support to 14 (for now), so we can easily upgrade
again once the autoroller issues are resolved (atm the chromium roller does not
have a libc++ with c++17 support).
|
| | |
|
| |
|
|
|
|
| |
It was apparently not being run anymore since it referred to a file
that was removed with asm2wasm. I suspect when we changed CI
we didn't keep running these. Anyhow they were just useful for
windows, which we have a lot more testing for now.
|
| |
|
|
|
|
|
| |
Now that fastcomp has been removed from Emscripten, there is no need
for the asm2wasm tool which it used to compile fastcomp's asm.js output
to wasm.
See emscripten-core/emscripten#11860
|
| | |
|
| | |
|
| | |
|
