{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":45208608,"defaultBranch":"main","name":"binaryen","ownerLogin":"WebAssembly","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2015-10-29T20:26:28.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/11578470?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1718154714.0","currentOid":""},"activityList":{"items":[{"before":null,"after":"72706b6a5ae6414b8c1292677c172dbb0dfb0bbd","ref":"refs/heads/set-shared-comptype","pushedAt":"2024-06-12T01:11:54.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"},"commit":{"message":"[SET] Parse, build, and print shared composite types\n\nParse the text format for shared composite types as described in the\nshared-everything thread proposal. Update the parser to use 'comptype' instead\nof 'strtype' to match the final GC spec and add the new syntactic class\n'sharecomptype'.\n\nUpdate the type canonicalization logic to take sharedness into account to avoid\nmerging shared and unshared types. Make the same change in the TypeMerging pass.\nEnsure that shared and unshared types cannot be in a subtype relationship with\neach other.\n\nFollow-up PRs will add shared abstract heap types, binary parsing and emitting\nfor shared types, and fuzzer support for shared types.","shortMessageHtmlLink":"[SET] Parse, build, and print shared composite types"}},{"before":"d24572143eab78cfccbd2a0033003dc75950b902","after":null,"ref":"refs/heads/parser-split-compilation","pushedAt":"2024-06-12T00:18:51.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"}},{"before":"425ecc65dea1a26c5b3667a46926a9834834b5cc","after":"475841dd5f0c50d7072f6dfc26dffd66e02abc10","ref":"refs/heads/main","pushedAt":"2024-06-12T00:18:50.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"},"commit":{"message":"[Parser][NFC] Split parser into multiple compilation units (#6653)\n\nBecause the parser has five stages, it requires instantiating all of the\r\ntemplates in parsers.h with up to five different contexts. Instantiating all\r\nthose templates in a single compilation unit takes a long time. On my machine, a\r\nrelease build of wat-parser.cpp.o took 32 seconds. To reduce the time of\r\nincremental rebuilds on machines with many cores, split the code across several\r\ncompilation units so that the templates need to be instantiated for just a\r\nsingle context in each unit. On my machine the longest compilation time after\r\nthis splitting is 17 seconds. The time for a full release build also drops from\r\n42 seconds to 33 seconds. On machines with fewer cores, the benefit may be\r\nsmaller or even negative, though.","shortMessageHtmlLink":"[Parser][NFC] Split parser into multiple compilation units (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2347479567\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6653\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6653/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6653\">#6653</a>)"}},{"before":"eae62b55bc0e6be1c624bcaabb6d9420a305f9bf","after":"d24572143eab78cfccbd2a0033003dc75950b902","ref":"refs/heads/parser-split-compilation","pushedAt":"2024-06-12T00:00:38.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"},"commit":{"message":"add missing file","shortMessageHtmlLink":"add missing file"}},{"before":null,"after":"eae62b55bc0e6be1c624bcaabb6d9420a305f9bf","ref":"refs/heads/parser-split-compilation","pushedAt":"2024-06-11T23:40:40.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"},"commit":{"message":"[Parser][NFC] Split parser into multiple compilation units\n\nBecause the parser has five stages, it requires instantiating all of the\ntemplates in parsers.h with up to five different contexts. Instantiating all\nthose templates in a single compilation unit takes a long time. On my machine, a\nrelease build of wat-parser.cpp.o took 32 seconds. To reduce the time of\nincremental rebuilds on machines with many cores, split the code across several\ncompilation units so that the templates need to be instantiated for just a\nsingle context in each unit. On my machine the longest compilation time after\nthis splitting is 17 seconds. The time for a full release build also drops from\n42 seconds to 33 seconds. On machines with fewer cores, the benefit may be\nsmaller or even negative, though.","shortMessageHtmlLink":"[Parser][NFC] Split parser into multiple compilation units"}},{"before":"5c3e64461aa8cf4e8b0e7a8b5c0421451dfc0fa0","after":null,"ref":"refs/heads/split-no-active","pushedAt":"2024-06-11T21:14:55.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"}},{"before":"2dcf67049ef4d2cbcb2a65d367be97ae675f9d8a","after":"425ecc65dea1a26c5b3667a46926a9834834b5cc","ref":"refs/heads/main","pushedAt":"2024-06-11T21:14:54.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"},"commit":{"message":"Fix wasm-split bug in absence of active element segments (#6651)\n\nThe module splitting code incorrectly assumed that there would be at least one\r\nactive element segment and failed to initialize the table slot manager with a\r\nfunction table if that was not the case. Fix the bug by setting the table even\r\nwhen there are no active segments and add a test.\r\n\r\nFixes #6572 and #6637.","shortMessageHtmlLink":"Fix wasm-split bug in absence of active element segments (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2347279033\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6651\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6651/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6651\">#6651</a>)"}},{"before":"cdd94a01ad02e944eaa9ba5e20a1129bef9ac305","after":"2dcf67049ef4d2cbcb2a65d367be97ae675f9d8a","ref":"refs/heads/main","pushedAt":"2024-06-11T21:13:52.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"kripken","name":"Alon Zakai","path":"/kripken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/173661?s=80&v=4"},"commit":{"message":"wasm2js: Add Table operations (#6650)\n\nTableGet, Set, Size, Grow, Fill, Copy.\r\n\r\nAlso move \"null\" into shared-constants, to make the code\r\nmore consistent overall.","shortMessageHtmlLink":"wasm2js: Add Table operations (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2347240553\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6650\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6650/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6650\">#6650</a>)"}},{"before":null,"after":"5c3e64461aa8cf4e8b0e7a8b5c0421451dfc0fa0","ref":"refs/heads/split-no-active","pushedAt":"2024-06-11T20:45:28.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"},"commit":{"message":"Fix wasm-split bug in absence of active element segments\n\nThe module splitting code incorrectly assumed that there would be at least one\nactive element segment and failed to initialize the table slot manager with a\nfunction table if that was not the case. Fix the bug by setting the table even\nwhen there are no active segments and add a test.\n\nFixes #6572.","shortMessageHtmlLink":"Fix wasm-split bug in absence of active element segments"}},{"before":"4002b79a788e9c5bf08b1f932645d4b2d8703255","after":null,"ref":"refs/heads/fix-slice-gets","pushedAt":"2024-06-11T20:11:05.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"}},{"before":"3d0e687447be426c4157dbe9c6d2626b147f85bf","after":"cdd94a01ad02e944eaa9ba5e20a1129bef9ac305","ref":"refs/heads/main","pushedAt":"2024-06-11T20:11:04.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"},"commit":{"message":"Fix scratch local optimizations when emitting string slice (#6649)\n\nThe binary writing of `stringview_wtf16.slice` requires scratch locals to store\r\nthe `start` and `end` operands while the string operand is converted to a\r\nstringview. To avoid unbounded binary bloat when round-tripping, we detect the\r\ncase that `start` and `end` are already `local.get`s and avoid using scratch\r\nlocals by deferring the binary writing of the `local.get` operands until after\r\nthe stringview conversoins is emitted.\r\n\r\nWe previously optimized the scratch locals for `start` and `end` independently,\r\nbut this could produce incorrect code in the case where the `local.get` for\r\n`start` is deferred but its value is changed by a `local.set` in the code for\r\n`end`. Fix the problem by only optimizing to avoid scratch locals in the case\r\nwhere both `start` and `end` are already `local.get`s, so they will still be\r\nemitted in the original relative order and they cannot interfere with each other\r\nanyway.","shortMessageHtmlLink":"Fix scratch local optimizations when emitting string slice (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2347132902\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6649\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6649/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6649\">#6649</a>)"}},{"before":null,"after":"4002b79a788e9c5bf08b1f932645d4b2d8703255","ref":"refs/heads/fix-slice-gets","pushedAt":"2024-06-11T19:26:53.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"},"commit":{"message":"Fix scratch local optimizations when emitting string slice\n\nThe binary writing of `stringview_wtf16.slice` requires scratch locals to store\nthe `start` and `end` operands while the string operand is converted to a\nstringview. To avoid unbounded binary bloat when round-tripping, we detect the\ncase that `start` and `end` are already `local.get`s and avoid using scratch\nlocals by deferring the binary writing of the `local.get` operands until after\nthe stringview conversoins is emitted.\n\nWe previously optimized the scratch locals for `start` and `end` independently,\nbut this could produce incorrect code in the case where the `local.get` for\n`start` is deferred but its value is changed by a `local.set` in the code for\n`end`. Fix the problem by only optimizing to avoid scratch locals in the case\nwhere both `start` and `end` are already `local.get`s, so they will still be\nemitted in the original relative order and they cannot interfere with each other\nanyway.","shortMessageHtmlLink":"Fix scratch local optimizations when emitting string slice"}},{"before":"0a1a59af573414a20fe457fd77b732729aa92fb2","after":"3d0e687447be426c4157dbe9c6d2626b147f85bf","ref":"refs/heads/main","pushedAt":"2024-06-10T23:15:46.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"kripken","name":"Alon Zakai","path":"/kripken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/173661?s=80&v=4"},"commit":{"message":"[Strings] Keep public and private types separate in StringLowering (#6642)\n\nWe need StringLowering to modify even public types, as it must replace every\r\nsingle stringref with externref, even if that modifies the ABI. To achieve that\r\nwe told it that all string-using types were private, which let TypeUpdater update\r\nthem, but the problem is that it moves all private types to a new single\r\nrec group, which meant public and private types ended up in the same group.\r\nAs a result, a single public type would make it all public, preventing optimizations\r\nand breaking things as in #6630 #6640.\r\n\r\nIdeally TypeUpdater would modify public types while keeping them in the same\r\nrec groups, but this may be a very specific issue for StringLowering, and that\r\nmight be a lot of work. Instead, just make StringLowering handle public types of\r\nfunctions in a manual way, which is simple and should handle all cases that\r\nmatter in practice, at least in J2Wasm.","shortMessageHtmlLink":"[Strings] Keep public and private types separate in StringLowering (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2334492980\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6642\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6642/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6642\">#…</a>"}},{"before":"76d1ac3e9c5abfe589bcdfc84b89f263bac7c574","after":"0a1a59af573414a20fe457fd77b732729aa92fb2","ref":"refs/heads/main","pushedAt":"2024-06-10T23:02:00.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"kripken","name":"Alon Zakai","path":"/kripken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/173661?s=80&v=4"},"commit":{"message":"wasm2js: Add basic reference operations (#6648)\n\nThis adds ref.eq, ref.null, ref.is_null, ref.func.","shortMessageHtmlLink":"wasm2js: Add basic reference operations (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2344777037\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6648\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6648/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6648\">#6648</a>)"}},{"before":"ea4d9e45e1b9a929a38fbca9a6c316b0b918b12e","after":"76d1ac3e9c5abfe589bcdfc84b89f263bac7c574","ref":"refs/heads/main","pushedAt":"2024-06-05T00:14:50.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"kripken","name":"Alon Zakai","path":"/kripken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/173661?s=80&v=4"},"commit":{"message":"Fix stack-use-after-scope on Windows in Precompute (#6643)\n\nCreate a temp var to store the ChildIterator.\r\n\r\nFixes #6639","shortMessageHtmlLink":"Fix stack-use-after-scope on Windows in Precompute (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2334551831\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6643\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6643/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6643\">#6643</a>)"}},{"before":"9347a223fcc1b6c297805b3c37fe1e7473158720","after":"ea4d9e45e1b9a929a38fbca9a6c316b0b918b12e","ref":"refs/heads/main","pushedAt":"2024-06-03T21:19:50.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"kripken","name":"Alon Zakai","path":"/kripken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/173661?s=80&v=4"},"commit":{"message":"Effects: Add missing combining logic for MayNotReturn (#6635)\n\nWithout that logic we could end up dropping that particular effect. This actually\r\nmade a test pass when it should not: the modified test here has a function with\r\neffects that are ok to remove, but it had a loop which adds MayNotReturn which\r\nwe should actually not remove, so it was removed erroneously.\r\n\r\nTo fix the test, add other effects there (local ones) that we can see are removable.\r\nAlso add a function with a loop to test that we do not remove an infinite loop,\r\nwhich adds coverage for the fix here.","shortMessageHtmlLink":"Effects: Add missing combining logic for MayNotReturn (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2326506107\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6635\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6635/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6635\">#6635</a>)"}},{"before":"1f2cd4f7b51c7afd6a6cafc4e48286e850bb36bd","after":"9347a223fcc1b6c297805b3c37fe1e7473158720","ref":"refs/heads/main","pushedAt":"2024-06-03T19:42:02.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"},"commit":{"message":"Fix binary parser of declarative element segments (#6618)\n\nThe parser was incorrectly handling the parsing of declarative element segments whose `init` is a `vec(expr)`.\r\nhttps://webassembly.github.io/spec/core/binary/modules.html#element-section\r\nBinry parser was simply reading a single `u32LEB` value for `init`\r\ninstead of parsing a expression regardless `usesExpressions = true`.\r\n\r\nThis commit updates the `WasmBinaryReader::readElementSegments` function\r\nto correctly parse the expressions for declarative element segments by\r\ncalling `readExpression` instead of `getU32LEB` when `usesExpressions = true`.\r\n\r\nResolves the parsing exception:\r\n\"[parse exception: bad section size, started at ... not being equal to new position ...]\"\r\n\r\nRelated discussion: https://github.com/tanishiking/scala-wasm/issues/136","shortMessageHtmlLink":"Fix binary parser of declarative element segments (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2307662144\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6618\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6618/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6618\">#6618</a>)"}},{"before":"40fd5b7a1abeb3b55be678688a1aeb530c720f2d","after":null,"ref":"refs/heads/emscrip_config","pushedAt":"2024-05-31T23:59:06.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"dschuff","name":"Derek Schuff","path":"/dschuff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1122856?s=80&v=4"}},{"before":"f8086adbf030b26eb7ce75e5d1834ae8134c689e","after":"1f2cd4f7b51c7afd6a6cafc4e48286e850bb36bd","ref":"refs/heads/main","pushedAt":"2024-05-31T23:59:05.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"dschuff","name":"Derek Schuff","path":"/dschuff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1122856?s=80&v=4"},"commit":{"message":"Make Emscripten CMake build more configurable (#6638)\n\nThis makes several changes to make the Emscripten build more configurable and\r\nconvenient for testing:\r\n\r\n1) Remove ERROR_ON_WASM_CHANGES_AFTER_LINK from ENABLE_BIGINT: this makes the\r\nsetting composable with optimized builds\r\n2) Add EMSCRIPTEN_ENABLE_MEMORY64 to build with the memory64 option\r\n3) Add EMSCRIPTEN_ENABLE_SINGLE_FILE to allow disabling the single-file build\r\n(to make it easier to analyze binary output)","shortMessageHtmlLink":"Make Emscripten CMake build more configurable (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2328704094\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6638\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6638/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6638\">#6638</a>)"}},{"before":null,"after":"40fd5b7a1abeb3b55be678688a1aeb530c720f2d","ref":"refs/heads/emscrip_config","pushedAt":"2024-05-31T23:16:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"dschuff","name":"Derek Schuff","path":"/dschuff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1122856?s=80&v=4"},"commit":{"message":"Make Emscripten CMake build more configurable\n\nThis makes several changes to make the Emscripten build more configurable and\nconvenient for testing:\n\n1) Remove ERROR_ON_WASM_CHANGES_AFTER_LINK from ENABLE_BIGINT: this makes the\nsetting composable with optimized builds\n2) Add EMSCRIPTEN_ENABLE_MEMORY64 to build with the memory64 option\n3) Add EMSCRIPTEN_ENABLE_SINGLE_FILE to allow disabling the single-file build\n(to make it easier to analyze binary output)","shortMessageHtmlLink":"Make Emscripten CMake build more configurable"}},{"before":"0c23394e9d73252000c3161fb33344ca7bbf247c","after":"f8086adbf030b26eb7ce75e5d1834ae8134c689e","ref":"refs/heads/main","pushedAt":"2024-05-31T21:55:57.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"kripken","name":"Alon Zakai","path":"/kripken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/173661?s=80&v=4"},"commit":{"message":"Optimize ReorderGlobals ordering with a new algorithm (#6625)\n\nThe old ordering in that pass did a topological sort while sorting by uses\r\nboth within topological groups and between them. That could be unoptimal\r\nin some cases, however, and actually on J2CL output this pass made the\r\nbinary larger, which is how we noticed this.\r\n\r\nThe problem is that such a toplogical sort keeps topological groups in\r\nplace, but it can be useful to interleave them sometimes. Imagine this:\r\n\r\n     $c - $a\r\n    /\r\n  $e\r\n    \\\r\n     $d - $b\r\n\r\nHere $e depends on $c, etc. The optimal order may interleave the two\r\narms here, e.g. $a, $b, $d, $c, $e. That is because the dependencies define\r\na partial order, and so the arms here are actually independent.\r\n\r\nSorting by toplogical depth first might help in some cases, but also is not\r\noptimal in general, as we may want to mix toplogical depths:\r\n$a, $c, $b, $d, $e does so, and it may be the best ordering.\r\n\r\nThis PR implements a natural greedy algorithm that picks the global with\r\nthe highest use count at each step, out of the set of possible globals, which\r\nis the set of globals that have no unresolved dependencies. So we start by\r\npicking the first global with no dependencies and add at at the front; then\r\nthat unlocks anything that depended on it and we pick from that set, and\r\nso forth.\r\n\r\nThis may also not be optimal, but it is easy to make it more flexible by\r\ncustomizing the counts, and we consider 4 sorts here:\r\n\r\n*   Set all counts to 0. This means we only take into account dependencies,\r\n    and we break ties by the original order, so this is as close to the original\r\n    order as we can be.\r\n*   Use the actual use counts. This is the simple greedy algorithm.\r\n*   Set the count of each global to also contain the counts of its children,\r\n    so the count is the total that might be unlocked. This gives more weight\r\n    to globals that can unlock more later, so it is less greedy.\r\n*   As last, but weight children's counts lower in an exponential way, which\r\n    makes sense as they may depend on other globals too.\r\n\r\nIn practice it is simple to generate cases where 1, 2, or 3 is optimal (see\r\nnew tests), but on real-world J2CL I see that 4 (with a particular exponential\r\ncoefficient) is best, so the pass computes all 4 and picks the best. As a\r\nresult it will never worsen the size and it has a good chance of\r\nimproving.\r\n\r\nThe differences between these are small, so in theory we could pick any\r\nof them, but given they are all modifications of a single algorithm it is\r\nvery easy to compute them all with little code complexity.\r\n\r\nThe benefits are rather small here, but this can save a few hundred\r\nbytes on a multi-MB Java file. This comes at a tiny compile time cost, but\r\nseems worth it for the new guarantee to never regress size.","shortMessageHtmlLink":"Optimize ReorderGlobals ordering with a new algorithm (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2311383120\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6625\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6625/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6625\">#6625</a>)"}},{"before":"18bb1f5af22b4d6bc309b96d844f856077eb6b60","after":"0c23394e9d73252000c3161fb33344ca7bbf247c","ref":"refs/heads/main","pushedAt":"2024-05-31T04:04:12.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"kripken","name":"Alon Zakai","path":"/kripken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/173661?s=80&v=4"},"commit":{"message":"LogExecution: Optionally take a module name for the logger function (#6629)\n\n--log-execution=NAME will use NAME as the module for the logger\r\nfunction import, rather than infer it.\r\n\r\nIf the name is not provided (--log-execution as before this PR) then we\r\nwill try to automatically decide which to use (\"env\", unless we see\r\nanother module name is used, which can be the case in optimized\r\nmodules).","shortMessageHtmlLink":"LogExecution: Optionally take a module name for the logger function (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2318845284\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6629\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6629/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6629\">#…</a>"}},{"before":"0148db0b081c4bf25cb91ef71f9aba5f7765e378","after":"18bb1f5af22b4d6bc309b96d844f856077eb6b60","ref":"refs/heads/main","pushedAt":"2024-05-30T20:44:18.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"kripken","name":"Alon Zakai","path":"/kripken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/173661?s=80&v=4"},"commit":{"message":"Avoid duplicate type names (#6633)\n\nIf we replace a type with another, use the original name for the new type,\r\nand give the old a unique name (for the rare cases in which it has uses).","shortMessageHtmlLink":"Avoid duplicate type names (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2326128799\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6633\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6633/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6633\">#6633</a>)"}},{"before":"5d90167464ef5709406aea7d87ad1657eec8618b","after":"0148db0b081c4bf25cb91ef71f9aba5f7765e378","ref":"refs/heads/main","pushedAt":"2024-05-30T19:49:24.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"kripken","name":"Alon Zakai","path":"/kripken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/173661?s=80&v=4"},"commit":{"message":"[NFC] Port LogExecution test to lit (#6634)","shortMessageHtmlLink":"[NFC] Port LogExecution test to lit (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2326310622\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6634\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6634/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6634\">#6634</a>)"}},{"before":"b85197cac4a295768f83133f7d01347ae2051276","after":"5d90167464ef5709406aea7d87ad1657eec8618b","ref":"refs/heads/main","pushedAt":"2024-05-29T23:49:59.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"kripken","name":"Alon Zakai","path":"/kripken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/173661?s=80&v=4"},"commit":{"message":"Fix Vacuuming of code leading up to an infinite loop (#6632)\n\nWe had that logic right in other places, but the specific part of Vacuum that\r\nlooks at code that leads up to an unreachable did not check for infinite loops,\r\nso it could remove them.","shortMessageHtmlLink":"Fix Vacuuming of code leading up to an infinite loop (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2324237315\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6632\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6632/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6632\">#6632</a>)"}},{"before":"56fe06220d558d300f3d49a036d637632ebd5ae4","after":"b85197cac4a295768f83133f7d01347ae2051276","ref":"refs/heads/main","pushedAt":"2024-05-29T23:48:55.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"kripken","name":"Alon Zakai","path":"/kripken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/173661?s=80&v=4"},"commit":{"message":"SignaturePruning: Properly handle public types (#6630)\n\nThe SignaturePruning pass optimizes away parameters that it proves are safe to\r\nremove. It turns out that that does not always match the definition of private\r\ntypes, which is more restrictive. Specifically, if say all the types are in one big\r\nrec group and one of them is used on an exported function then all of them are\r\nconsidered public (as the rec group is). However, in closed world, it would be ok\r\nto leave that rec group unchanged but to create a pruned version of that type\r\nand use it, in cases where we see it is safe to remove a parameter. (See the\r\ntestcase for a concrete example.)\r\n\r\nTo put it another way, SignaturePruning already proves that a parameter is\r\nsafe to remove in all the ways that matter. Before this PR, however, the testcase\r\nin this PR would error - so this PR is not an optimization but a bugfix, really -\r\nbecause SignaturePruning would see that a parameter is safe to remove but\r\nthen TypeUpdating would see the type is public and so it would leave it alone,\r\nleading to a broken module.\r\n\r\nThis situation is in fact not that rare, and happens on real-world Java code.\r\nThe reason we did not notice it before is that typically there are no remaining\r\nSignaturePruning opportunities late in the process (when other closed world\r\noptimizations have typically led to a single big rec group).\r\n\r\nThe concrete fix here is to add additionalPrivateTypes to a few more places\r\nin TypeUpdating. We already supported that for cases where a pass knew\r\nbetter than the general logic what can be modified, and this adds that\r\nability to the signature-rewriting logic there. Then SignaturePruning can\r\nsend in all the types it has proven are safe to modify.\r\n\r\n *  Also necessary here is to only add from additionalPrivateTypes if the type\r\n    is not already in our list (or we'd end up with duplicates in the final rec\r\n    group).\r\n*   Also move newSignatures in SignaturePruning out of the top level, which\r\n    was confusing (the pass has multiple iterations, and we want each to have\r\n    a fresh instance).","shortMessageHtmlLink":"SignaturePruning: Properly handle public types (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2323907609\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6630\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6630/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6630\">#6630</a>)"}},{"before":"116b2e47ee7f18093b4ad10f5d5137c280fd57d1","after":null,"ref":"refs/heads/wasm-shell-fix","pushedAt":"2024-05-29T22:40:44.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"}},{"before":"d844d2e77b402d562ade8cf8fd96759b587bf09d","after":"56fe06220d558d300f3d49a036d637632ebd5ae4","ref":"refs/heads/main","pushedAt":"2024-05-29T22:40:44.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"},"commit":{"message":"[NFC] Save a line in wasm-shell.cpp (#6631)","shortMessageHtmlLink":"[NFC] Save a line in wasm-shell.cpp (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2324213058\" data-permission-text=\"Title is private\" data-url=\"https://github.com/WebAssembly/binaryen/issues/6631\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/WebAssembly/binaryen/pull/6631/hovercard\" href=\"https://github.com/WebAssembly/binaryen/pull/6631\">#6631</a>)"}},{"before":null,"after":"116b2e47ee7f18093b4ad10f5d5137c280fd57d1","ref":"refs/heads/wasm-shell-fix","pushedAt":"2024-05-29T20:40:48.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"},"commit":{"message":"[NFC] Save a line in wasm-shell.cpp","shortMessageHtmlLink":"[NFC] Save a line in wasm-shell.cpp"}},{"before":"59738642dfd96e7270dd9ca1435c465dcfecec1b","after":null,"ref":"refs/heads/delete-old-parser","pushedAt":"2024-05-29T18:32:27.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"tlively","name":"Thomas Lively","path":"/tlively","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/7121787?s=80&v=4"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEYsmM4QA","startCursor":null,"endCursor":null}},"title":"Activity · WebAssembly/binaryen"}