profile
viewpoint
Max Graey MaxGraey Kyiv, Ukraine WebAssembly enthusiast. @AssemblyScript core team member.

MaxGraey/Assembleash 74

WebAssembly and Typescript-like languages playground

AssemblyScript/node 43

Implementations of the node.js APIs for use with AssemblyScript.

MaxGraey/as-bignum 32

Fixed length big numbers for AssemblyScript 🚀

AssemblyScript/working-group 18

Discussions, goals, roadmaps, assets, etc. directly related to AssemblyScript development or project organization.

MaxGraey/atom-dark-fusion-syntax 16

Flat and color balanced dark theme for maximum readability

ChainSafe/as-sha256 9

AssemblyScript implementation of SHA256

MaxGraey/assemblyscript-compiler-bench 1

AssemblyScript and Rust compile benchmark inspired by V (vlang) ;-)

MaxGraey/awesome-wasm 1

😎 Curated list of awesome things regarding WebAssembly (wasm) ecosystem.

MaxGraey/binding.js 1

Bind and watch updating property or member changes of javascript object or DOM-element

MaxGraey/a-big-triangle 0

Draws a big triangle onto the screen

push eventMaxGraey/binaryen

MaxGraey

commit sha c9fe2cbf6137a841e5c8bff50cf8aab830c6c0ec

add basic tests

view details

push time in 17 minutes

push eventMaxGraey/binaryen

MaxGraey

commit sha d93f65d8e7af39667f8f4cf6b095a42e047ac7a6

fixture refresh

view details

push time in an hour

push eventMaxGraey/binaryen

MaxGraey

commit sha 60b7b55fe739163dae6de79de1d88bf0d22b6290

lint

view details

push time in 2 hours

pull request commentWebAssembly/binaryen

Implement more cases for getMaxBits

Latest change enchained assert error little bit. It now looks like this: Снимок экрана 2020-08-05 в 00 35 04

MaxGraey

comment created time in 2 hours

push eventMaxGraey/binaryen

MaxGraey

commit sha fd4e8cf0360b575e38f4b4254550bd3ffd86008c

more fancy unit test error output

view details

push time in 2 hours

push eventMaxGraey/binaryen

MaxGraey

commit sha 252ce01c6bedf48d5c40acbfe0ed00c959c247f0

more fixes after resolving conflicts

view details

push time in 2 hours

push eventMaxGraey/binaryen

MaxGraey

commit sha 3ea4530375d511762243c80deed4272023ee4a24

cleanups

view details

push time in 3 hours

push eventMaxGraey/binaryen

Alon Zakai

commit sha 0efd168824ac58abaf8ac484460a43241882dc93

wasm2js fuzzing: properly ignore trapping code (#2980) wasm2js fuzzing should not compare outputs if the wasm would trap. wasm2js traps on far fewer things, and if wasm would trap (like an indirect call with the wrong type) it can just do weird undefined things. Previously, if running wasm2js trapped then we ignored the output, but that't not good enough, as we need to check if wasm would, exactly for the cases just mentioned where wasm would trap but wasm2js wouldn't. So run the wasm interpreter to see if that happens. When we see such a trap, ignore everything from that function call onwards. This at least lets us compare the results of previous calls, which adds some amount of coverage (before we just ignored the entire output completely, so only if there was no trap at all did we do any comparisons at all). Also give better names than "js.js" to the JS files wasm2js fuzzing creates.

view details

Alon Zakai

commit sha 1f231c39e52eab712eda9bcbf540752b813b567d

Wasm2c fuzz support: only emit a call to the hang limit function if present (#2977) It may not be present while reducing a testcase, if the reducer removed it.

view details

Sam Clegg

commit sha c0cbee736291e75bfe78c726de3fa065ee167a50

Update flags used in generate_lld_tests (#2981) The `--no-gc-sections` was added as part of #2857 but is not needed and in fact changes the output of some tests. `--experimental-pic` is needed these days when building shared libraries with emscripten's abi. After these two changes I verfied that the following command generated no local changes (i.e. is a no-op): ./scripts/test/generate_lld_tests.py --binaryen-bin=$PWD/../binaryen-out/bin/ $PWD/../llvm-build/bin/ $PWD/../emscripten

view details

Sam Clegg

commit sha dad719e97b8461f31d29faebe2f15ad4843c0417

Move ReplaceStackPoint into a pass (#2984) First step in making wasm-emscripten-finalize use more passes.

view details

Sam Clegg

commit sha 109f9fef53c16afaf1ced4149c9b2536adca0c2c

Move emscripten PIC ABI conversion to a pass. NFC. (#2985) Doing it this way happens to re-order the __assign_got_entries function in the module, but its otherwise NFC.

view details

Sam Clegg

commit sha 7ee1440d3fb3bca01df8213dae13a8ed1fd34bd6

wasm-emscripten-finalize: remove exportWasiStart (#2986) This should not be needed since in emscripten standalone mode we always include a crt1.o that includes _start.

view details

Max Graey

commit sha 85e45a4371ef9e6b143e9675d5f52136ef881c12

Some minor improvements for binaryen.js epilogue (#2947) Simplify stack allocation and array generation logic.

view details

Sam Clegg

commit sha 32ab8bac04af52121c6985a9a019c0fdec957f03

Move stack-check into its own pass (#2994) This new pass takes an optional stack-check-handler argument which is the name of the function to call on stack overflow. If no argument is passed then it just traps.

view details

Alon Zakai

commit sha 26f240c72dd62ed8a39f7466df99e51ec34487aa

wasm2js: Don't remove an | 0 or >>> 0 in a boolean context (#2993) It is usually fine to do if (x | 0) => if (x) since it just cares if the value is 0 or not. However, if the cast turns it into 0, then that is incorrect, which the fuzzer found as -2147483648 + -2147483648 | 0 (the sum is 2^32, which | 0 is 0). We can maybe look into doing this in a safe way, but for now just remove it. It doesn't have a big impact on code size as this is pretty rare (e.g. the minimal runtime code size test is not broken by this).

view details

Alon Zakai

commit sha 63d60fef3b07a343e21fb4bb8227c4e674633704

Fix the side effects of data.drop (#2996) We marked it as readsMemory so that it could be reordered with various things, except for memory.init. However, the fuzzer found that's not quite right, as it has a global side effect - memory.inits that run later can notice that. So it can't be reordered with anything that might affect global side effects from happening, as in the testcase added here (an instruction that may trap cannot be reordered with a data.drop, as it may prevent the data.drop from happening and changing global state). There may be a way to optimize this more carefully that would allow more optimizations, but as this is a rare instruction I'm not sure it's worth more work.

view details

Alon Zakai

commit sha fceb216b9ad28dabc8c0fd5790b544d5d64acf64

AvoidReinterprets should not remove code around a reinterpret's value's fallthrough (#2989) We can turn a reinterpret of a load into a different load, and so forth, but if the reinterpret has a non-load child with a load fallthrough, that's not good enough - we can't remove the extra code: (reinterpret (block ..extra code.. (load) ) ) That can't be turned into a load of the flipped type.

view details

Sam Clegg

commit sha 0fa3b823576001e00fbb9e3e7c10ecb9a050c422

Remove dynCall generated from fpcast-emu (#2995) This is precursor to moving dynCall generation into a pass of its own. It seems to be up to the caller if they want to run dynCall generation either before or after fpcast-emu. Verified that this change does not effect emscripten's wasm2 other other test suite.

view details

Max Graey

commit sha 74f0eeff6f9cedf40e32e60595475ec243e8c35e

binaryen.js: use ECMASCRIPT6 for Closure Compiler (#2990)

view details

Alon Zakai

commit sha 95a33d7e3233c0f00b0043bb2225d514ae1cd10e

wasm2js: Remove an incorrect optimization (#3004) optimizeBoolean does not receive a boolean, it is done when the output flows into a boolean context.

view details

Max Graey

commit sha 4253dae801b7f5526c28c4bbd8cda1d32067344d

Fix build for win32 (#3001) Check for x64 before using a non-32bit operation. See #2955 for context.

view details

Alon Zakai

commit sha f8cd0ad7e2aa389ac04c5978ed9d654bdcf1e22f

wasm2js: Add an "Export" scope for name resolution (#2998) Previously we used "Top" for both exports and the top level (which has functions and globals). The warning about name collisions there was meant only for exports (where if a name collides and so it must be renamed, means that there will be an externally-visible oddness for the user). But it applied to functions too, which could be annoying, and was not dangerous (at worst, it might be confusing when reading the emitted JS and seeing NAME_1, NAME_2, but there is no effect on execution or on exports). To fix this, add a new Export name scope. This separates function names from export names. However, it runs into another issue which is that when checking for a name conflict we had a big set of all the names in all the scopes. That is, FOO would only ever be used in one scope, period, and other appearances of that Name in wasm would get a suffix. As a result, if an exported function FOO has the name foo, we'd export it as FOO but name the function FOO_1 which is annoying. To fix that, keep sets of all names in each scope. When mangling a name we can then only care about the relevant scope, EXCEPT for local names, which must also not conflict with function names. That is, this would be bad: function foo(bar) { var bar = 0; } function bar() { .. It's not ok to call a parameter "bar" if there is a function by that name (well, it could be if it isn't called in that scope). So when mangling the Local scope, also check the Top one as well. The test output changes are due to non-overlapping scopes, specifically Local and Label. It's fine to have foo : while(1) { var foo = 5; } Those "foo"s do not conflict. Fixes emscripten-core/emscripten#11743

view details

Alon Zakai

commit sha 6733a055fd7873210b6f3b50f198ae05178ec8fb

Better const fuzzing (#2972) Tweak floating-point numbers with not just a +-1 integer, but also a float in [-1, 1]. Apply a tweak to powers of 2 as well. This found bugs in various codebases, see WebAssembly/spec#1224

view details

rathann

commit sha 26060b2cfe835e208d29e12d70a1a8eee70b3c14

Specify UTF-8 encoding instead of relying on locale default (#3009) Current locale may not be UTF-8, which makes the spec/names.wast test fail. Fixes issue #3003.

view details

Alon Zakai

commit sha d09c607ff2f2c264546b7d4ea3593ae75a037750

New Dealign pass: reduce load/store alignment to 1 (#3010) Pretty trivial, but will be useful in wasm2js testing, where we can't assume an incorrectly-aligned load/store will still work, so we'll need to be pessimistic about alignment there.

view details

Alon Zakai

commit sha ae56f9919a7263c7f8df00f0552ee0f302f8d286

AlignmentLowering: Handle all possible cases for i64, f32, f64 (#3008) Previously we only handled i32. That was enough for all real-world code people have run through wasm2js apparently (which is the only place the pass is needed - it lowers unaligned loads to individual loads etc., as unaligned operations fail in JS). Apparently it's pretty rare to have unaligned f32 loads for example. This will be useful in fuzzing wasm2js, as without this we can't compare results to the interpreter (which does alignment properly).

view details

push time in 3 hours

push eventMaxGraey/binaryen

Alon Zakai

commit sha d78c794ffd61946bf2035042cbda082f042272db

Refactor getMaxBits() out of OptimizeInstructions and add beginnings of unit testing for it (#3019) getMaxBits just moves around, no logic is changed. Aside from adding getMaxBits, the change in bits.h is 99% whitespace. helps #2879

view details

push time in 3 hours

issue commentAssemblyScript/assemblyscript

[Feature] Allow decorators on exports

How about this?

/** @deprecated */
type foo = Foo;

export { foo };

Btw it should support by TS language server.

willemneal

comment created time in 4 hours

issue commentAssemblyScript/assemblyscript

[Feature] Allow decorators on exports

Ah, you want deprecate only alias storage but not Storage?

willemneal

comment created time in 4 hours

Pull request review commentAssemblyScript/assemblyscript

feat: String interpolation

 assert(dtoa(0.000035689) == "0.000035689"); // assert(dtoa(f32.MAX_VALUE) == "3.4028234663852886e+38"); // FIXME // assert(dtoa(f32.EPSILON) == "1.1920928955078125e-7"); // FIXME +// Basic case mapping tests+assert("".toUpperCase() == "");+assert("".toLowerCase() == "");+assert("09_AZ az.!\n".toUpperCase() == "09_AZ AZ.!\n");+assert("09_AZ az.!\t".toLowerCase() == "09_az az.!\t");+assert("Der Wechsel allein ist das Beständige".toUpperCase() == "DER WECHSEL ALLEIN IST DAS BESTÄNDIGE");+assert("DER WECHSEL ALLEIN IST DAS BESTÄNDIGE".toLowerCase() == "der wechsel allein ist das beständige");+assert("@ — Друг человека!".toUpperCase() == "@ — ДРУГ ЧЕЛОВЕКА!");+assert("@ — ДРУГ ЧЕЛОВЕКА!".toLowerCase() == "@ — друг человека!");+assert("∮ E⋅da = Q, n → ∞, ∑ f(i) = ∏ g(i)".toUpperCase() == "∮ E⋅DA = Q, N → ∞, ∑ F(I) = ∏ G(I)");+assert("∮ E⋅DA = Q, N → ∞, ∑ F(I) = ∏ G(I)".toLowerCase() == "∮ e⋅da = q, n → ∞, ∑ f(i) = ∏ g(i)");+assert("ði ıntəˈnæʃənəl fəˈnɛtık əsoʊsiˈeıʃn".toUpperCase() == "ÐI INTƏˈNÆƩƏNƏL FƏˈNƐTIK ƏSOƱSIˈEIƩN");+assert("ÐI INTƏˈNÆƩƏNƏL FƏˈNƐTIK ƏSOƱSIˈEIƩN".toLowerCase() == "ði intəˈnæʃənəl fəˈnɛtik əsoʊsiˈeiʃn");+assert("Σὲ γνωρίζω ἀπὸ τὴν κόψη".toUpperCase() == "ΣῈ ΓΝΩΡΊΖΩ ἈΠῸ ΤῊΝ ΚΌΨΗ");+assert("τοῦ σπαθιοῦ τὴν τρομερή,".toUpperCase() == "ΤΟΥ͂ ΣΠΑΘΙΟΥ͂ ΤῊΝ ΤΡΟΜΕΡΉ,");+assert("σὲ γνωρίζω ἀπὸ τὴν ὄψη".toUpperCase() == "ΣῈ ΓΝΩΡΊΖΩ ἈΠῸ ΤῊΝ ὌΨΗ");+assert("ποὺ μὲ βία μετράει τὴ γῆ.".toUpperCase() == "ΠΟῪ ΜῈ ΒΊΑ ΜΕΤΡΆΕΙ ΤῊ ΓΗ͂.");+assert("Απ᾿ τὰ κόκκαλα βγαλμένη".toUpperCase() == "ΑΠ᾿ ΤᾺ ΚΌΚΚΑΛΑ ΒΓΑΛΜΈΝΗ");+assert("τῶν ῾Ελλήνων τὰ ἱερά".toUpperCase() == "ΤΩ͂Ν ῾ΕΛΛΉΝΩΝ ΤᾺ ἹΕΡΆ");+assert("καὶ σὰν πρῶτα ἀνδρειωμένη".toUpperCase() == "ΚΑῚ ΣᾺΝ ΠΡΩ͂ΤΑ ἈΝΔΡΕΙΩΜΈΝΗ");+assert("χαῖρε, ὦ χαῖρε, ᾿Ελευθεριά!".toUpperCase() == "ΧΑΙ͂ΡΕ, Ὦ ΧΑΙ͂ΡΕ, ᾿ΕΛΕΥΘΕΡΙΆ!");+assert(+  "ABCDEFGHIJKLMNOPQRSTUVWXYZ /0123456789abcdefghijklmnopqrstuvwxyz".toUpperCase() ==+  "ABCDEFGHIJKLMNOPQRSTUVWXYZ /0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"+);+assert(+  "ABCDEFGHIJKLMNOPQRSTUVWXYZ /0123456789abcdefghijklmnopqrstuvwxyz".toLowerCase() ==+  "abcdefghijklmnopqrstuvwxyz /0123456789abcdefghijklmnopqrstuvwxyz"+);+assert("ß".toUpperCase() == "SS");+assert("İ".toLowerCase() == "i̇"); // 0x0130+assert(+  "£©µÀÆÖÞßéöÿ–—‘“”„†•…‰™œŠŸž€ ΑΒΓΔΩαβγδω АБВГДабвгд∀∂∈ℝ∧∪≡∞ ↑↗↨↻⇣ ┐┼╔╘░►☺♀ fi�⑀₂ἠḂӥẄɐː⍎אԱა".toUpperCase() ==+  "£©ΜÀÆÖÞSSÉÖŸ–—‘“”„†•…‰™ŒŠŸŽ€ ΑΒΓΔΩΑΒΓΔΩ АБВГДАБВГД∀∂∈ℝ∧∪≡∞ ↑↗↨↻⇣ ┐┼╔╘░►☺♀ FI�⑀₂ἨḂӤẄⱯː⍎אԱᲐ"+);+assert("ß".toUpperCase().toLowerCase() == "ss");+assert("fi".toUpperCase().toLowerCase() == "fi");+assert(+  "𠜎 𠜱 𠝹 𠱓 𠱸 𠲖 𠳏 𠳕 𠴕 𠵼 𠵿 𠸎 𠸏 𠹷 𠺝 𠺢 𠻗 𠻹 𠻺 𠼭 𠼮 𠽌 𠾴 𠾼 𠿪 𡁜 𡁯 𡁵 𡁶 𡁻 𡃁"+  .toUpperCase().toLowerCase() ==+  "𠜎 𠜱 𠝹 𠱓 𠱸 𠲖 𠳏 𠳕 𠴕 𠵼 𠵿 𠸎 𠸏 𠹷 𠺝 𠺢 𠻗 𠻹 𠻺 𠼭 𠼮 𠽌 𠾴 𠾼 𠿪 𡁜 𡁯 𡁵 𡁶 𡁻 𡃁"+);++assert(String.fromCodePoint(0x10000).toLowerCase() == "𐀀");+assert(String.fromCodePoint(0x10000).toUpperCase() == "𐀀");++// Tests some special casing for lower case mapping+assert("\u1F88".toLowerCase() == "\u1F80");+assert("\u1F8F".toLowerCase() == "\u1F87");+assert("\u1FFC".toLowerCase() == "\u1FF3");++// Tests some special casing for upper case mapping+assert("\uFB00".toUpperCase() == "FF");+assert("\uFB01".toUpperCase() == "FI");+assert("\uFB02".toUpperCase() == "FL");+assert("\uFB03".toUpperCase() == "FFI");+assert("\uFB04".toUpperCase() == "FFL");+assert("\uFB05".toUpperCase() == "ST");+assert("\uFB06".toUpperCase() == "ST");+assert("\u01F0".toUpperCase() == "J\u030C");+assert("\u1E96".toUpperCase() == "H\u0331");+assert("\u1E97".toUpperCase() == "T\u0308");+assert("\u1E98".toUpperCase() == "W\u030A");+assert("\u1E99".toUpperCase() == "Y\u030A");+assert("\u1E9A".toUpperCase() == "A\u02BE");++// Test full unicode range `0x0 - 0x10FFFF` and asserting with v8 engine.+for (let i = 0; i <= 0x10FFFF; i++) {+  let source = String.fromCodePoint(i);+  let origLower = source.toLowerCase();+  let origUpper = source.toUpperCase();+  let code1: u64, code2: u64;++  // collect all code points for lower case on AssemblyScript side+  let origLowerCode = <u64>origLower.codePointAt(0);+  if ((code1 = origLower.codePointAt(1)) >= 0) origLowerCode += <u64>code1 << 16;+  if ((code2 = origLower.codePointAt(2)) >= 0) origLowerCode += <u64>code2 << 32;++  // collect all code points for upper case on AssemblyScript side+  let origUpperCode = <u64>origUpper.codePointAt(0);+  if ((code1 = origUpper.codePointAt(1)) >= 0) origUpperCode += <u64>code1 << 16;+  if ((code2 = origUpper.codePointAt(2)) >= 0) origUpperCode += <u64>code2 << 32;++  // collect all code points for lower case on JavaScript side+  let expectLowerCode = <u64>toLowerCaseFromIndex(i, 0);+  if ((code1 = <i64>toLowerCaseFromIndex(i, 1)) >= 0) expectLowerCode += <u64>code1 << 16;+  if ((code2 = <i64>toLowerCaseFromIndex(i, 2)) >= 0) expectLowerCode += <u64>code2 << 32;++  // collect all code points for upper case on JavaScript side+  let expectUpperCode = <u64>toUpperCaseFromIndex(i, 0);+  if ((code1 = <i64>toUpperCaseFromIndex(i, 1)) >= 0) expectUpperCode += <u64>code1 << 16;+  if ((code2 = <i64>toUpperCaseFromIndex(i, 2)) >= 0) expectUpperCode += <u64>code2 << 32;++  if (origLowerCode != expectLowerCode) {+    trace("origLowerCode != expectLowerCode", 3, i, <f64>origLowerCode, <f64>expectLowerCode);+  }++  if (origUpperCode != expectUpperCode) {+    trace("origUpperCode != expectUpperCode", 3, i, <f64>origUpperCode, <f64>expectUpperCode);+ }++  assert(origLowerCode == expectLowerCode);+  assert(origUpperCode == expectUpperCode);+}+++

All this block of tests transferred to tests/compiler/std/string-casemapping.ts. I guess it just appear after conflict merging

developerfred

comment created time in 4 hours

issue commentAssemblyScript/assemblyscript

[Feature] Allow decorators on exports

Isn't better use such decorator for Storage class instead over export keyword?

willemneal

comment created time in 4 hours

pull request commentWebAssembly/binaryen

Replace x * 2 to x + x for float points

Yeah, even with temporary local it save 1 byte for f32. Approach suggested by @binji save one more byte.

MaxGraey

comment created time in 5 hours

pull request commentWebAssembly/binaryen

Replace x * 2 to x + x for float points

Perhaps, but also you may be adding a local here. Would be good to do some concrete measurements (for various cases, where the value has side effects and when it doesn't, etc.).

It happening only for side effects and relatively costly expressions I guess. But even with this it should be take a benefit in size compare to x * 2. I'll check this for f32.

MaxGraey

comment created time in 5 hours

Pull request review commentWebAssembly/binaryen

Extend ZeroRemover for handling 64-bit integers as well

 struct OptimizeInstructions       // nothing much to do, except for the trivial case of adding/subbing a       // zero       if (auto* c = binary->right->dynCast<Const>()) {-        if (c->value.geti32() == 0) {+        if (c->value.getInteger() == 0LL) {           return binary->left;         }       }       return nullptr;     }     // wipe out all constants, we'll replace with a single added one     for (auto* c : constants) {-      c->value = Literal(int32_t(0));+      c->value = Literal::makeFromInt32(0, c->type);

I tried make this agnostic to type of zero. May be this not perfect? Could you suggest better approach?

MaxGraey

comment created time in 5 hours

push eventMaxGraey/binaryen

Max Graey

commit sha b44c1af1eb3c4900863b1b4e6b96713cbdb98609

Modernize binaryen.js glue code (#3005)

view details

push time in 7 hours

delete branch MaxGraey/binaryen

delete branch : refactor-binaryen-post-js

delete time in 7 hours

pull request commentWebAssembly/binaryen

fix compilation warnings for gcc unit tests

The error seems to be intended as part of test_nonvalid // create a module that fails to validate:

Ah, good to know. Thanks!

MaxGraey

comment created time in 10 hours

issue commentAssemblyScript/assemblyscript

Are tuples supported?

Sure, but for efficiently implement tuples / records we waiting wide support for multi-values

maskon

comment created time in 12 hours

issue commentAssemblyScript/assemblyscript

Are tuples supported?

No, tuples not supported yet.

Are there any workarounds?

Any of next variants:

const data = [2, 9.9];  // deduced as `data: f64[]`
const data: f64[] = [2, 9.9];  // explicit declare of type
const data = [2, 9.9] as f64[];  // ^
const data = [2 as f64, 9.9]; // ^

// more efficient fixed sized arrays:
const data: StaticArray<f64> = [2, 9.9];
maskon

comment created time in 12 hours

pull request commentWebAssembly/binaryen

fix compilation warnongs for gcc unit tests

Also after run ./check.py gcc I got this:

[wasm-validator error in function func] local.set's value type must be correct, on 
[none] (local.set $0
 [i64] (i64.const 1234)
)
  (no trace in  c-api-kitchen-sink.txt )
  (no trace in  c-api-kitchen-sink.txt.txt )
MaxGraey

comment created time in 13 hours

Pull request review commentWebAssembly/binaryen

fix compilation warnongs for gcc unit tests

 def run_gcc_tests():             # build the C file separately             libpath = os.path.join(os.path.dirname(shared.options.binaryen_bin),  'lib')             extra = [shared.NATIVECC, src, '-c', '-o', 'example.o',-                     '-I' + os.path.join(shared.options.binaryen_root, 'src'), '-g', '-L' + libpath, '-pthread']+                     '-I' + os.path.join(shared.options.binaryen_root, 'src'), '-g', '-pthread']

It seems this don't needed due to there are compilation via -c, not linking

MaxGraey

comment created time in 13 hours

PR opened WebAssembly/binaryen

fix compilation warnongs for gcc unit tests
+15 -15

0 comment

4 changed files

pr created time in 13 hours

create barnchMaxGraey/binaryen

branch : fix-tests

created branch time in 13 hours

pull request commentWebAssembly/binaryen

Implement prototype v128.load{32,64}_zero instructions

It seems it also require some test suite changes. When I try run ./auto_update_tests.py script I got:

[parse exception: v128.load32_zero (at 1148:2)]
Fatal: error parsing wasm
Traceback (most recent call last):
  File "./auto_update_tests.py", line 260, in <module>
    sys.exit(main())
  File "./auto_update_tests.py", line 254, in main
    TEST_SUITES[test]()
  File "/Volumes/Archive/Projects/Github/binaryen/scripts/test/wasm_opt.py", line 187, in update_wasm_opt_tests
    actual = support.run_command(cmd)
  File "/Volumes/Archive/Projects/Github/binaryen/scripts/test/support.py", line 176, in run_command
    raise Exception(('run_command failed (%s)' % code, out + str(err or '')))
Exception: ('run_command failed (1)', '')

tlively

comment created time in 14 hours

issue commentWebAssembly/binaryen

Duplicated unary / binary expression ellimination

I see, thanks

MaxGraey

comment created time in 17 hours

push eventMaxGraey/binaryen

Max Graey

commit sha 79f2fe4eb4197b3f2a1f8ad0c3a34bf9c28149a1

Use consistent backquotes instead ordinal quotes for Grain in README (#3017)

view details

Thomas Lively

commit sha daa442b40f92ee5117c9c7c391171c3304abc67e

Implement prototype v128.load{32,64}_zero instructions (#3011) Specified in https://github.com/WebAssembly/simd/pull/237. Since these are just prototypes necessary for benchmarking, this PR does not add support for these instructions to the fuzzer or the C or JS APIs. This PR also renumbers the QFMA instructions that previously used the opcodes for these new instructions. The renumbering matches the renumbering in V8 and LLVM.

view details

push time in a day

Pull request review commentWebAssembly/binaryen

Modernize binaryen.js glue code

 Module['TupleMake'] = makeExpressionWrapper({       Module['_BinaryenTupleMakeRemoveOperandAt'](expr, --prevNumOperands);     }   },-  'getOperandAt': function(expr, index) {+  'getOperandAt'(expr, index) {

It introduced with ES6 / ES2015 so it's not widely known

MaxGraey

comment created time in a day

pull request commentWebAssembly/binaryen

Replace x * 2 to x + x for float points

LLVM do the same transform so this useful mostly for languages which uses Binaryen as prime optimizer or it could be useful for js2wasm scenario.

MaxGraey

comment created time in a day

issue commentWebAssembly/binaryen

Duplicated unary / binary expression ellimination

I guess such cases like (x | y) | y | y .... | y better handle via PostWalker and better create mist walker like ZeroRemover, right?

Regarding splitting OptimizeInstructions. By what criterion is it better to divide? It might be worth doing separation by kind of expressions: OptimizeBinaryInstructions, OptimizeUnaryInstructions, ``OptimizeSelectInstruction` and etc?

MaxGraey

comment created time in a day

pull request commentWebAssembly/binaryen

Replace x * 2 to x + x for float points

Why do you expect this would decrease code size? How much of an improvement do you see?

As I understand float / double values don't variable encode as integers, so 2.0 always takes 8 bytes. Replacing x * 2 to x + x we could save up to 7 bytes

MaxGraey

comment created time in a day

push eventMaxGraey/binaryen

MaxGraey

commit sha 104fb42b32cc3530591120887d6f90784668c104

make sure we always do 64-bit inversion for floats

view details

push time in a day

pull request commentAssemblyScript/assemblyscript

minor improvements for pass pipeline

For npm run test:compiler -- --create (and via ts-node) roughly comparison: master: 80896 ms this pr: 77528 ms

MaxGraey

comment created time in a day

push eventMaxGraey/binaryen

MaxGraey

commit sha 8c9b4584432ee2668deba9a09bab9326ec944814

refactor

view details

push time in a day

push eventMaxGraey/binaryen

MaxGraey

commit sha 13c34f8ace736a5014adf47ec68f12e47c74763f

32-bit float pot impl

view details

push time in a day

push eventMaxGraey/binaryen

MaxGraey

commit sha c61aa138d604ed0d690ab4ec0690fc4f304e8996

remove namespace prefixes

view details

push time in a day

push eventMaxGraey/binaryen

MaxGraey

commit sha 90d9915e51fab8f4da204a3e26de9525d235f4c1

fix?

view details

MaxGraey

commit sha 6ada67bdfa030c4965589d11ae522cfe9e3ea8b8

refactor IsPowerOf2Float + use bit_cast

view details

push time in a day

delete branch MaxGraey/binaryen

delete branch : improve-readme

delete time in a day

push eventMaxGraey/binaryen

MaxGraey

commit sha 49386800c2b3df6cb2009d8760d1c032bf29c831

avoid hexfloats which not support in C++14

view details

push time in a day

pull request commentAssemblyScript/assemblyscript

minor improvements for pass pipeline

Basically this attempts also speedup pipeline by doing some work earlier, before SSA and flattering. In my internal tests it's really little bit faster than previous scheme.

Where do we draw the line? How much slowdown are we willing to accept for what gain? And how can we measure this as a function of time taken vs code optimized?

It's will be great have some compiler benchmark ideally integrated with CI

MaxGraey

comment created time in a day

push eventMaxGraey/binaryen

MaxGraey

commit sha 8b04e1ef7db3acc7fc92e96eb980fba57fa32d69

refactor

view details

push time in a day

push eventMaxGraey/binaryen

MaxGraey

commit sha 3d1fe28a2041b811928321f9e97d3a182a0f6dee

lint

view details

push time in a day

Pull request review commentWebAssembly/binaryen

Optimize power of two float divisions

 function asmFunc(global, env, buffer) {    function $7($0) {   $0 = Math_fround($0);-  i64toi32_i32$HIGH_BITS = Math_fround(Math_abs($0)) >= Math_fround(1.0) ? ($0 > Math_fround(0.0) ? ~~Math_fround(Math_min(Math_fround(Math_floor(Math_fround($0 / Math_fround(4294967296.0)))), Math_fround(4294967296.0))) >>> 0 : ~~Math_fround(Math_ceil(Math_fround(Math_fround($0 - Math_fround(~~$0 >>> 0 >>> 0)) / Math_fround(4294967296.0)))) >>> 0) : 0;+  i64toi32_i32$HIGH_BITS = Math_fround(Math_abs($0)) >= Math_fround(1.0) ? ($0 > Math_fround(0.0) ? ~~Math_fround(Math_min(Math_fround(Math_floor(Math_fround($0 * Math_fround(2.3283064365386963e-10)))), Math_fround(4294967296.0))) >>> 0 : ~~Math_fround(Math_ceil(Math_fround(Math_fround($0 - Math_fround(~~$0 >>> 0 >>> 0)) * Math_fround(2.3283064365386963e-10)))) >>> 0) : 0;   return ~~$0 >>> 0 | 0;  }    function $9($0) {   $0 = +$0;-  i64toi32_i32$HIGH_BITS = Math_abs($0) >= 1.0 ? ($0 > 0.0 ? ~~Math_min(Math_floor($0 / 4294967296.0), 4294967295.0) >>> 0 : ~~Math_ceil(($0 - +(~~$0 >>> 0 >>> 0)) / 4294967296.0) >>> 0) : 0;+  i64toi32_i32$HIGH_BITS = Math_abs($0) >= 1.0 ? ($0 > 0.0 ? ~~Math_min(Math_floor($0 * 2.3283064365386963e-10), 4294967295.0) >>> 0 : ~~Math_ceil(($0 - +(~~$0 >>> 0 >>> 0)) * 2.3283064365386963e-10) >>> 0) : 0;

I'm wondering could we skip this rule only for wasm2js? I didn't find any specific flag which helps determine compilation target of binaryen

MaxGraey

comment created time in a day

PR opened WebAssembly/binaryen

Optimize power of two float divisions

x / C_pot -> x * (1 / C_pot) where C_pot is pow of two float point

+52 -4

0 comment

4 changed files

pr created time in a day

create barnchMaxGraey/binaryen

branch : opt-fdiv-w-pot-consts

created branch time in a day

issue commenttc39/proposal-record-tuple

Collect developer feedback about the ergonomics of `#{ }`/`#[ ]`

What if complicatedly dissociate from arrays and objects and use rounded brackets for both tuples and records?

let tuple = #(1, 2, 3);
let record = #(a: 1. b: 2, c: 3);

let alsoTuple1 = #(0: 1, 1: 2, 3: 3);
let alsoTuple12= #('0': 1, '1': 2, '3': 3);

Rounded brackets also much with tuple's syntax of many other languages

littledan

comment created time in a day

push eventMaxGraey/assemblyscript

MaxGraey

commit sha b70d049e52103e4bda9bb0b8178dd7d1b3034001

early merge blocks

view details

push time in 2 days

push eventMaxGraey/assemblyscript

MaxGraey

commit sha 2fba78013eeaaef19f438dbe2676103f71bafbe0

better

view details

push time in 2 days

push eventMaxGraey/assemblyscript

MaxGraey

commit sha 72984f53f0251dd855c3805697ee19e1089d6e58

Revert "remove unnecessary opt instrusion pass" This reverts commit f1f1022c7efab3b894f0e7364e3a1fb471b3ae90.

view details

push time in 2 days

push eventMaxGraey/assemblyscript

MaxGraey

commit sha f1f1022c7efab3b894f0e7364e3a1fb471b3ae90

remove unnecessary opt instrusion pass

view details

push time in 2 days

push eventMaxGraey/assemblyscript

MaxGraey

commit sha 6cba9a212bd9d120bc5fcf5be9f70053e71821af

early glob optimization

view details

push time in 2 days

push eventMaxGraey/assemblyscript

MaxGraey

commit sha 112160a6cd96d133a5ab63c830becd5bace7d635

Revert "what if..." This reverts commit a05e3e12ddb6171e6dc129b6d7480704da0d74de.

view details

push time in 2 days

push eventMaxGraey/assemblyscript

MaxGraey

commit sha a05e3e12ddb6171e6dc129b6d7480704da0d74de

what if...

view details

push time in 2 days

push eventMaxGraey/assemblyscript

MaxGraey

commit sha 4186f49759ee983cf5c4e0c89662531ae06da7d1

Revert "simplify-locals-nostructure -> simplify-locals-notee-nostructure" This reverts commit 0be3cf6a27e6657fe78dcf9ef98250955434b974.

view details

push time in 2 days

push eventMaxGraey/assemblyscript

MaxGraey

commit sha 0be3cf6a27e6657fe78dcf9ef98250955434b974

simplify-locals-nostructure -> simplify-locals-notee-nostructure

view details

push time in 2 days

PR opened AssemblyScript/assemblyscript

Slightly improve pass pipeline

Add more pre-SSA passes like simplify-locals-notee-nostructure and more redundant set elimination before SSA.

  • [x] I've read the contributing guidelines
+3015 -2967

0 comment

37 changed files

pr created time in 2 days

create barnchMaxGraey/assemblyscript

branch : pipeline

created branch time in 2 days

create barnchMaxGraey/binaryen

branch : improve-readme

created branch time in 2 days

issue closedWebAssembly/binaryen

[Feature request] Caching mutable globals to locals in function scope

On some bench which read from globals inside loop this may increase speed on 10% but also increase size a little bit. And obviously should not apply to globals which are involved in atomics operations

closed time in 2 days

MaxGraey

issue closedWebAssembly/binaryen

[Proposal] Move directize pass before inlining-optimizing

According to my experiments will be great if directize pass will be before inlining-optimizing because directized function could be pretty simple and definitely make sense inline it. For example:

function sort<T>(arr: T[], cmp: (a: T, b: T) => i32): void {
   ...
   if (cmp(arr[i], arr[j]) < 0) {
     ...
   }
}

sort(arr, (a, b) => a - b);

after directize, dae-optimizing and inlining-optimizing passes becomes:

function sort<T>(arr: T[]): void {
   ...
   if ((arr[i] - arr[j]) < 0) {
      ...
   }
}

Or even better: arr[i] < arr[j] But currently this not happening with -O4. It require additional inlining-optimizing pass.

closed time in 2 days

MaxGraey

fork MaxGraey/vscode-witx

WITX language support for VSCode

fork in 2 days

pull request commentWebAssembly/binaryen

Implement more cases for getMaxBits

Instead, how about moving the getMaxBits logic into a separate file (maybe src/support/bits.h/cpp? not sure)

I'm also not sure. getMaxBits more relate to ir. How about place it to src/ir/bits.h ?

MaxGraey

comment created time in 2 days

pull request commentWebAssembly/binaryen

Replace x * 2 to x + x for float points

fuzzed until ITERATION: 30799

MaxGraey

comment created time in 2 days

push eventMaxGraey/binaryen

MaxGraey

commit sha 70e494b185d9b33dfd353467bccf1a02851bbf74

always use localizer

view details

push time in 2 days

push eventMaxGraey/binaryen

MaxGraey

commit sha b7e6df62974b60fb66da69331d51ae2a02f86e5d

lint

view details

push time in 2 days

push eventMaxGraey/binaryen

MaxGraey

commit sha ccf273c265c2fbb50353425e5bbe47c00f49cc83

better handle side effect via loacalizer

view details

push time in 2 days

push eventMaxGraey/binaryen

MaxGraey

commit sha d5404b3a800c216bec220dd6b3d4410e795701ff

add tests

view details

push time in 2 days

push eventMaxGraey/binaryen

MaxGraey

commit sha 0951ba203267ea4addb2e555295a5aef5c4c37a1

lint

view details

push time in 3 days

startedhomenc/HElib

started time in 3 days

PR opened WebAssembly/binaryen

Replace x * 2 to x + x for float points if possible

It seems this may drastically reduce binary size.

+32 -15

0 comment

4 changed files

pr created time in 3 days

create barnchMaxGraey/binaryen

branch : replace-float-mul-2-to-sum

created branch time in 3 days

issue commentWebAssembly/binaryen

More simplifications

x * 2.0 -> x + x

It seems this transform may reduce 7 bytes? Hmm cc @kripken

MaxGraey

comment created time in 3 days

issue commentWebAssembly/binaryen

More simplifications

x / C_pot -> x * (1 / C_pot)

where x -> float point, C_pot power of two float constant

MaxGraey

comment created time in 3 days

push eventMaxGraey/grain

Willem Wyndham

commit sha 6c55c300816f18f11c568e8dec5c6e5e2046151e

fix: update asc and add asconfig.json

view details

MaxGraey

commit sha 2cd2f5b76680a5836db2c04f5905bff15859b50d

update AssemblyScript + minor fixes and improvments

view details

Oscar Spencer

commit sha bd618ee92789fe5d635a2ef5ded79af66cb049d2

Merge pull request #233 from willemneal/update_asc fix: update asc and add asconfig.json

view details

Oscar Spencer

commit sha 349c02d4ff658d31a0d921f1fb86686fde9e81ef

Merge pull request #234 from MaxGraey/update-as update AssemblyScript + minor fixes and improvments

view details

Oscar Spencer

commit sha 0b5795f5e576729ef74180cdacffa7a05be15615

Optimize stdlib AS for speed rather than size

view details

Oscar Spencer

commit sha ad16d53d06164fe3ae5dc4587d9647a11869f6ef

Merge pull request #235 from grain-lang/ospencer-patch-1 Optimize stdlib AS for speed rather than size

view details

push time in 3 days

push eventMaxGraey/binaryen

MaxGraey

commit sha 5a2438493ee0c810ddac771909950f76d183bb33

lint

view details

push time in 3 days

PR opened WebAssembly/binaryen

Extend ZeroRemover for handling 64-bit integers as well

It turned out that ZeroRemover and optimizeAddedConstants method don't handle 64-bit values. Current PR fixes this. Also added makeFromInt64 for Literal class.

+117 -36

0 comment

4 changed files

pr created time in 3 days

create barnchMaxGraey/binaryen

branch : generalize-zero-remover

created branch time in 3 days

issue openedWebAssembly/binaryen

Duplicate unary / binary expression ellimination

Many unary duplicate unary operations could be eliminated. Like: ~(~x) -> x -(-x) -> x abs(abs(x)) -> abs(x) ceil(ceil(x)) -> ceil(x) floor(floor(x)) -> floor(x) trunc(trunc(x)) -> trunc(x) nearest(nearest(x)) -> nearest(x) etc

and some binary: y - (y - x) -> x int only (x ^ y) ^ y -> x (x | y) | y -> x | y (x & y) & y -> x & y etc

I think it should be something general like ZeroRemover and call it like Deduplicator or DupRemover which walk recursively. Thoughts?

created time in 3 days

push eventWebAssembly-Enthusiasts/info

MaxGraey

commit sha 92641940592ae506a297d890961605e64cbfc434

(fix): correct path to resources in FAQ.md

view details

push time in 3 days

Pull request review commentgrain-lang/grain

fix: update asc and add asconfig.json

+{+  "options": {+    "-O3z": true,

How so?

AssemblyScript uses conditionally compiled branches specialized for speed and / or size. Sometimes for good size reduction we use compleately different implementations.

Is this a binaryen issue?

Binaryen's also sensitive to level of shrinkage. Especially on inlining

willemneal

comment created time in 3 days

Pull request review commentgrain-lang/grain

fix: update asc and add asconfig.json

+{+  "options": {+    "-O3z": true,

Btw it was -O3 before. It's could significant affected on performance for memory.copy / memory.compare

willemneal

comment created time in 3 days

delete branch MaxGraey/grain

delete branch : update-as

delete time in 3 days

pull request commentgrain-lang/grain

update AssemblyScript + minor fixes and improvments

This looks like it will break some things, since Grain uses a custom malloc implementation. Is there a new specification for memory.data that can hook into our malloc

memory.data is not allocate heap instead it reserve some static memory in static section. It pretty useful for temporary allocated objects which lifetime bounds in one function's body. It's reduce memory pressure and unnecessary alloc / frees

MaxGraey

comment created time in 3 days

Pull request review commentWebAssembly/binaryen

Refactor types to represent arbitrarily complex types

 inline uint64_t rehash(uint64_t x, uint64_t y) {   return rehash(ret, HashType(y >> 32)); } +template<typename T> inline void hash_combine(std::size_t& s, const T& v) {+  // see boost/container_hash/hash.hpp+  s ^= std::hash<T>{}(v) + 0x9e3779b9 + (s << 6) + (s >> 2);

Hmm, I don't know. But will be good keep this in mind

dcodeIO

comment created time in 3 days

pull request commentgrain-lang/grain

update AssemblyScript + minor fixes and improvments

Oh, I see it little bit covered #233 =)

MaxGraey

comment created time in 3 days

PR opened grain-lang/grain

update AssemblyScript + minor fixes and improvments
  • update AssemblyScript to latest
  • avoid some alloc / free by usings static memory (memory.data)
  • minor fixes and style improvments
+59 -73

0 comment

8 changed files

pr created time in 3 days

create barnchMaxGraey/grain

branch : update-as

created branch time in 3 days

fork MaxGraey/grain

The Grain compiler toolchain and CLI. Home of the modern web staple. 🌾

https://grain-lang.org/

fork in 3 days

issue commentAssemblyScript/assemblyscript

decorator gets not called

Yes but It's not high priority in different reasons currently. First of all JS/TS decorators is not yes standardized. Next reason it's required some kind of macro system deeply integrated with AST which require some efforts for design and implementation. But AssemblyScript already has access to AST in slightly different manner - it's called transforms and already used by many projects for implement custom decorators. See offficial example: https://github.com/AssemblyScript/examples/tree/master/transform

Also you may interesting in some utils like visitor helper: https://github.com/willemneal/visitor-as

exellian

comment created time in 3 days

issue commentAssemblyScript/assemblyscript

decorator gets not called

Currently only built-in decorators are supported

exellian

comment created time in 3 days

Pull request review commentWebAssembly/binaryen

Refactor types to represent arbitrarily complex types

 inline uint64_t rehash(uint64_t x, uint64_t y) {   return rehash(ret, HashType(y >> 32)); } +template<typename T> inline void hash_combine(std::size_t& s, const T& v) {+  // see boost/container_hash/hash.hpp+  s ^= std::hash<T>{}(v) + 0x9e3779b9 + (s << 6) + (s >> 2);

It seems std::hash is not the best hash function. I guess using xxHash will be better in term of speed and quality

dcodeIO

comment created time in 3 days

push eventMaxGraey/binaryen

MaxGraey

commit sha eb29bb5e4b644119829dfbaae60175cd3a373a84

refactor a bit

view details

push time in 3 days

push eventMaxGraey/binaryen

MaxGraey

commit sha 8b4176699257d9e6f8c1a44bc1647e1e51dad06c

add more transforms

view details

push time in 3 days

push eventMaxGraey/binaryen

MaxGraey

commit sha 51da9e2e3dae86a3fc4dccc3ec56c504529d9883

add more complex tests

view details

push time in 3 days

PR opened WebAssembly/binaryen

Add float simplification for identically squared absolute expressions

abs(x) * abs(x) -> x * x where x is any float type.

+102 -0

0 comment

3 changed files

pr created time in 3 days

create barnchMaxGraey/binaryen

branch : opt-squared-fabs

created branch time in 3 days

more