{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":101767772,"defaultBranch":"main","name":"wasmtime","ownerLogin":"bytecodealliance","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2017-08-29T14:01:55.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/54038801?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1717799100.0","currentOid":""},"activityList":{"items":[{"before":"6e2b43104e41fc17ac672cefbfcf6225e52172e2","after":"3f3a1428c288adce9aa68c69ecf52b172d81355a","ref":"refs/heads/gh-pages","pushedAt":"2024-06-07T22:45:59.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deploying to gh-pages from @ bytecodealliance/wasmtime@af59c4d568d487b7efbb49d7d31a861e7c3933a6 ๐","shortMessageHtmlLink":"Deploying to gh-pages from @ af59c4d ๐"}},{"before":"af59c4d568d487b7efbb49d7d31a861e7c3933a6","after":null,"ref":"refs/heads/gh-readonly-queue/main/pr-8758-96c905a6e3f371010a124685b87f666a14513f1e","pushedAt":"2024-06-07T22:39:25.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"}},{"before":"96c905a6e3f371010a124685b87f666a14513f1e","after":"af59c4d568d487b7efbb49d7d31a861e7c3933a6","ref":"refs/heads/main","pushedAt":"2024-06-07T22:39:24.000Z","pushType":"merge_queue_merge","commitsCount":1,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"},"commit":{"message":"Make module ids unique per-process, not per-engine (#8758)\n\n* Make module ids unique per-process, not per-engine\n\nCurrently all instances of `wasmtime::Module` have a unique 64-bit id\nembedded into them. This ID was originally only used for affinity in the\npooling allocator as a quick check of module equality. This use case\nonly required engine-local ids so the initial implementation had an ID\nallocator per-engine.\n\nLater, however, this id was reused for `wasmtime::ModuleExport` which\nwas intended to skip the string lookup for an export at runtime. This\nalso stored a module id but it did not store an engine identifier. This\nmeant that it's possible to mix these up and pass the wrong export to\nthe wrong engine. This behavior can lead to a runtime panic in Wasmtime.\n\nThis commit fixes this by making the module identifier be global\nper-process instead of per-engine. This mirrors how store IDs are\nallocated where they're per-process instead of per-engine. The same\nlogic for why store IDs are unlikely to be exhausted applies here too\nwhere this 64-bit space of identifiers is unlikely to be exhausted.\n\n* Fix warnings\n\n* Fix tests","shortMessageHtmlLink":"Make module ids unique per-process, not per-engine (#8758)"}},{"before":null,"after":"af59c4d568d487b7efbb49d7d31a861e7c3933a6","ref":"refs/heads/gh-readonly-queue/main/pr-8758-96c905a6e3f371010a124685b87f666a14513f1e","pushedAt":"2024-06-07T22:25:00.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"},"commit":{"message":"Make module ids unique per-process, not per-engine (#8758)\n\n* Make module ids unique per-process, not per-engine\n\nCurrently all instances of `wasmtime::Module` have a unique 64-bit id\nembedded into them. This ID was originally only used for affinity in the\npooling allocator as a quick check of module equality. This use case\nonly required engine-local ids so the initial implementation had an ID\nallocator per-engine.\n\nLater, however, this id was reused for `wasmtime::ModuleExport` which\nwas intended to skip the string lookup for an export at runtime. This\nalso stored a module id but it did not store an engine identifier. This\nmeant that it's possible to mix these up and pass the wrong export to\nthe wrong engine. This behavior can lead to a runtime panic in Wasmtime.\n\nThis commit fixes this by making the module identifier be global\nper-process instead of per-engine. This mirrors how store IDs are\nallocated where they're per-process instead of per-engine. The same\nlogic for why store IDs are unlikely to be exhausted applies here too\nwhere this 64-bit space of identifiers is unlikely to be exhausted.\n\n* Fix warnings\n\n* Fix tests","shortMessageHtmlLink":"Make module ids unique per-process, not per-engine (#8758)"}},{"before":"d9a10d1f122cd0e58e732fde5aaa71999da59ccc","after":"6e2b43104e41fc17ac672cefbfcf6225e52172e2","ref":"refs/heads/gh-pages","pushedAt":"2024-06-07T13:31:16.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deploying to gh-pages from @ bytecodealliance/wasmtime@96c905a6e3f371010a124685b87f666a14513f1e ๐","shortMessageHtmlLink":"Deploying to gh-pages from @ 96c905a ๐"}},{"before":"96c905a6e3f371010a124685b87f666a14513f1e","after":null,"ref":"refs/heads/gh-readonly-queue/main/pr-8755-890a19e91e45b1ca13646a2c060d56350ee55341","pushedAt":"2024-06-07T13:27:13.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"}},{"before":"890a19e91e45b1ca13646a2c060d56350ee55341","after":"96c905a6e3f371010a124685b87f666a14513f1e","ref":"refs/heads/main","pushedAt":"2024-06-07T13:27:12.000Z","pushType":"merge_queue_merge","commitsCount":1,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"},"commit":{"message":"Recommend `-O opt-level=0` when debugging wasm (#8755)\n\n* Recommend `-O opt-level=0` when debugging wasm\n\nThis improves inspection of local variables by avoiding the egraph pass\nwhich doesn't have full fidelity in terms of preserving debug\ninformation.\n\n* Fix example compile","shortMessageHtmlLink":"Recommend -O opt-level=0 when debugging wasm (#8755)"}},{"before":null,"after":"96c905a6e3f371010a124685b87f666a14513f1e","ref":"refs/heads/gh-readonly-queue/main/pr-8755-890a19e91e45b1ca13646a2c060d56350ee55341","pushedAt":"2024-06-07T13:13:14.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"},"commit":{"message":"Recommend `-O opt-level=0` when debugging wasm (#8755)\n\n* Recommend `-O opt-level=0` when debugging wasm\n\nThis improves inspection of local variables by avoiding the egraph pass\nwhich doesn't have full fidelity in terms of preserving debug\ninformation.\n\n* Fix example compile","shortMessageHtmlLink":"Recommend -O opt-level=0 when debugging wasm (#8755)"}},{"before":"cec92833b998f2c44e84578cbcfbf2e28e393c71","after":null,"ref":"refs/heads/revert-8754-fix-dwarf-in-ci","pushedAt":"2024-06-07T04:45:00.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"alexcrichton","name":"Alex Crichton","path":"/alexcrichton","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/64996?s=80&v=4"}},{"before":null,"after":"cec92833b998f2c44e84578cbcfbf2e28e393c71","ref":"refs/heads/revert-8754-fix-dwarf-in-ci","pushedAt":"2024-06-07T04:44:36.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alexcrichton","name":"Alex Crichton","path":"/alexcrichton","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/64996?s=80&v=4"},"commit":{"message":"Revert \"Fix some aspects of running debug tests in CI (#8754)\"\n\nThis reverts commit 890a19e91e45b1ca13646a2c060d56350ee55341.","shortMessageHtmlLink":"Revert \"Fix some aspects of running debug tests in CI (#8754)\""}},{"before":"380e9dce881b00440c85dae72567e83b949b7214","after":"d9a10d1f122cd0e58e732fde5aaa71999da59ccc","ref":"refs/heads/gh-pages","pushedAt":"2024-06-07T04:37:03.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deploying to gh-pages from @ bytecodealliance/wasmtime@890a19e91e45b1ca13646a2c060d56350ee55341 ๐","shortMessageHtmlLink":"Deploying to gh-pages from @ 890a19e ๐"}},{"before":"890a19e91e45b1ca13646a2c060d56350ee55341","after":null,"ref":"refs/heads/gh-readonly-queue/main/pr-8754-59de3a32f245976a7e895985dea5081b3448a150","pushedAt":"2024-06-07T04:31:51.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"}},{"before":"59de3a32f245976a7e895985dea5081b3448a150","after":"890a19e91e45b1ca13646a2c060d56350ee55341","ref":"refs/heads/main","pushedAt":"2024-06-07T04:31:51.000Z","pushType":"merge_queue_merge","commitsCount":1,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"},"commit":{"message":"Fix some aspects of running debug tests in CI (#8754)\n\n* Fix some aspects of running debug tests in CI\n\nThis commit fixes the filter used to run tests in CI to include all\ndebug with a broader filter to include the whole `debug` module of\ntests. This fixes a mistake where recent tests added weren't running in\nCI.\n\nThis then additionally adds a `run-dwarf` filter in CI to run these\ntests on any changes to filenames containing \"debug\" in the name.\n\n* Test out the marker to run dwarf tests in CI\n\nprtest:debug","shortMessageHtmlLink":"Fix some aspects of running debug tests in CI (#8754)"}},{"before":"161d46024dd43bb8227da3c0bd9df6f1407fe9fc","after":"380e9dce881b00440c85dae72567e83b949b7214","ref":"refs/heads/gh-pages","pushedAt":"2024-06-07T04:24:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deploying to gh-pages from @ bytecodealliance/wasmtime@59de3a32f245976a7e895985dea5081b3448a150 ๐","shortMessageHtmlLink":"Deploying to gh-pages from @ 59de3a3 ๐"}},{"before":"59de3a32f245976a7e895985dea5081b3448a150","after":null,"ref":"refs/heads/gh-readonly-queue/main/pr-8728-7a37e313d26b825d81425de67e33d775a0bc1114","pushedAt":"2024-06-07T04:20:12.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"}},{"before":"7a37e313d26b825d81425de67e33d775a0bc1114","after":"59de3a32f245976a7e895985dea5081b3448a150","ref":"refs/heads/main","pushedAt":"2024-06-07T04:20:10.000Z","pushType":"merge_queue_merge","commitsCount":1,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"},"commit":{"message":"Cranelift: Allow CLIF frontends to define their own stack maps (#8728)\n\nTracking GC references and producing stack maps is a significant amount of\ncomplexity in `regalloc2`.\n\nAt the same time, GC reference value types are pretty annoying to deal with in\nCranelift itself. We know our `r64` is \"actually\" just an `i64` pointer, and we\nwant to do `i64`-y things with it, such as an `iadd` to compute a derived\npointer, but `iadd` only takes integer types and not `r64`s. We investigated\nloosening that restriction and it was way too painful given the way that CLIF\ntype inference and its controlling type vars work. So to compute those derived\npointers, we have to first `bitcast` the `r64` into an `i64`. This is\nunfortunate in two ways. First, because of arcane interactions between register\nallocation constraints, stack maps, and ABIs this involves inserting unnecessary\nregister-to-register moves in our generated code which hurts binary size and\nperformance ever so slightly. Second, and much more seriously, this is a serious\nfootgun. If a GC reference isn't an `r64` right now, then it will not appear in\nstack maps, and failure to record a live GC reference in a stack map means that\nthe collector could reclaim the object while you are still using it, leading to\nuse-after-free bugs! Very bad. And the mid-end needs to know\n*not* to GVN these bitcasts or else we get similar bugs (see\nhttps://github.com/bytecodealliance/wasmtime/pull/8317).\n\nOverall GC references are a painful situation for us today.\n\nThis commit is the introduction of an alternative. (Note, though, that we aren't\nquite ready to remove the old stack maps infrastructure just yet.)\n\nInstead of preserving GC references all the way through the whole pipeline and\ncomputing live GC references and inserting spills at safepoints for stack maps\nall the way at the end of that pipeline in register allocation, the\nCLIF-producing frontend explicitly generates its own stack slots and spills for\nsafepoints. The only thing the rest of the compiler pipeline needs to know is\nthe metadata required to produce the stack map for the associated safepoint. We\ncan completely remove `r32` and `r64` from Cranelift and just use plain `i32`\nand `i64` values. Or `f64` if the runtime uses NaN-boxing, which the old stack\nmaps system did not support at all. Or 32-bit GC references on a 64-bit target,\nwhich was also not supported by the old system. Furthermore, we *cannot* get\nmiscompiles due to GVN'ing bitcasts that shouldn't be GVN'd because there aren't\nany bitcasts hiding GC references from stack maps anymore. And in the case of a\nmoving GC, we don't need to worry about the mid-end doing illegal code motion\nacross calls that could have triggered a GC that invalidated the moved GC\nreference because frontends will reload their GC references from the stack slots\nafter the call, and that loaded value simply isn't a candidate for GVN with the\nprevious version. We don't have to worry about those bugs by construction.\n\nSo everything gets a lot easier under this new system.\n\nBut this commit doesn't mean we are 100% done and ready to transition to the new\nsystem, so what is actually in here?\n\n* CLIF producers can mark values as needing to be present in a stack map if they\nare live across a safepoint in `cranelift-frontend`. This is the\n`FunctionBuilder::declare_needs_stack_map` method.\n\n* When we finalize the function we are building, we do a simple, single-pass\nliveness analysis to determine the set of GC references that are live at each\nsafepoint, and then we insert spills to explicit stack slots just before the\nsafepoint. We intentionally trade away the precision of a fixed-point liveness\nanalysis for the speed and simplicity of a single-pass implementation.\n\n* We annotate the safepoint with the metadata necessary to construct its\nassociated stack map. This is the new\n`cranelift_codegen::ir::DataFlowGraph::append_user_stack_map_entry` method and\nall that stuff.\n\n* These stack map entries are part of the CLIF and can be roundtripped through\nprinting and parsing CLIF.\n\n* Each stack map entry describes a GC-managed value that is on the stack and how\nto locate it: its type, the stack slot it is located within, and the offset\nwithin that stack slot where it resides. Different stack map entries for the\nsame safepoint may have different types or a different width from the target's\npointer.\n\nHere is what is *not* handled yet, and left for future follow up commits:\n\n* Lowering the stack map entries' locations from symbolic stack slot and offset\npairs to physical stack frame offsets after register allocation.\n\n* Coalescing and aggregating the safepoints and their raw stack map entries into\na compact PC-to-stack-map table during emission.\n\n* Supporting moving GCs. Right now we generate spills into stack slots for live\nGC references just before safepoints, but we don't reload the GC references from\nthe stack upon their next use after the safepoint. This involves rewriting uses\nof the old, spilled values which could be a little finicky, but we think we have\na good approach.\n\n* Port Wasmtime over to using this new stack maps system.\n\n* Removing the old stack map system, including `r{32,64}` from Cranelift and GC\nreference handling from `regalloc2`. (For the time being, the new system\ngenerally refers to \"user stack maps\" to disambiguate from the old system where\nit might otherwise be confusing.) If we wanted to remove the old system now,\nthat would require us to also port Wasmtime to the new system now, and we'd end\nup with a monolithic PR. Better to do this incrementally and temporarily have\nthe old and in-progress new system overlap for a short period of time.\n\nCo-authored-by: Trevor Elliott ","shortMessageHtmlLink":"Cranelift: Allow CLIF frontends to define their own stack maps (#8728)"}},{"before":null,"after":"890a19e91e45b1ca13646a2c060d56350ee55341","ref":"refs/heads/gh-readonly-queue/main/pr-8754-59de3a32f245976a7e895985dea5081b3448a150","pushedAt":"2024-06-07T04:16:42.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"},"commit":{"message":"Fix some aspects of running debug tests in CI (#8754)\n\n* Fix some aspects of running debug tests in CI\n\nThis commit fixes the filter used to run tests in CI to include all\ndebug with a broader filter to include the whole `debug` module of\ntests. This fixes a mistake where recent tests added weren't running in\nCI.\n\nThis then additionally adds a `run-dwarf` filter in CI to run these\ntests on any changes to filenames containing \"debug\" in the name.\n\n* Test out the marker to run dwarf tests in CI\n\nprtest:debug","shortMessageHtmlLink":"Fix some aspects of running debug tests in CI (#8754)"}},{"before":null,"after":"59de3a32f245976a7e895985dea5081b3448a150","ref":"refs/heads/gh-readonly-queue/main/pr-8728-7a37e313d26b825d81425de67e33d775a0bc1114","pushedAt":"2024-06-07T04:06:11.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"},"commit":{"message":"Cranelift: Allow CLIF frontends to define their own stack maps (#8728)\n\nTracking GC references and producing stack maps is a significant amount of\ncomplexity in `regalloc2`.\n\nAt the same time, GC reference value types are pretty annoying to deal with in\nCranelift itself. We know our `r64` is \"actually\" just an `i64` pointer, and we\nwant to do `i64`-y things with it, such as an `iadd` to compute a derived\npointer, but `iadd` only takes integer types and not `r64`s. We investigated\nloosening that restriction and it was way too painful given the way that CLIF\ntype inference and its controlling type vars work. So to compute those derived\npointers, we have to first `bitcast` the `r64` into an `i64`. This is\nunfortunate in two ways. First, because of arcane interactions between register\nallocation constraints, stack maps, and ABIs this involves inserting unnecessary\nregister-to-register moves in our generated code which hurts binary size and\nperformance ever so slightly. Second, and much more seriously, this is a serious\nfootgun. If a GC reference isn't an `r64` right now, then it will not appear in\nstack maps, and failure to record a live GC reference in a stack map means that\nthe collector could reclaim the object while you are still using it, leading to\nuse-after-free bugs! Very bad. And the mid-end needs to know\n*not* to GVN these bitcasts or else we get similar bugs (see\nhttps://github.com/bytecodealliance/wasmtime/pull/8317).\n\nOverall GC references are a painful situation for us today.\n\nThis commit is the introduction of an alternative. (Note, though, that we aren't\nquite ready to remove the old stack maps infrastructure just yet.)\n\nInstead of preserving GC references all the way through the whole pipeline and\ncomputing live GC references and inserting spills at safepoints for stack maps\nall the way at the end of that pipeline in register allocation, the\nCLIF-producing frontend explicitly generates its own stack slots and spills for\nsafepoints. The only thing the rest of the compiler pipeline needs to know is\nthe metadata required to produce the stack map for the associated safepoint. We\ncan completely remove `r32` and `r64` from Cranelift and just use plain `i32`\nand `i64` values. Or `f64` if the runtime uses NaN-boxing, which the old stack\nmaps system did not support at all. Or 32-bit GC references on a 64-bit target,\nwhich was also not supported by the old system. Furthermore, we *cannot* get\nmiscompiles due to GVN'ing bitcasts that shouldn't be GVN'd because there aren't\nany bitcasts hiding GC references from stack maps anymore. And in the case of a\nmoving GC, we don't need to worry about the mid-end doing illegal code motion\nacross calls that could have triggered a GC that invalidated the moved GC\nreference because frontends will reload their GC references from the stack slots\nafter the call, and that loaded value simply isn't a candidate for GVN with the\nprevious version. We don't have to worry about those bugs by construction.\n\nSo everything gets a lot easier under this new system.\n\nBut this commit doesn't mean we are 100% done and ready to transition to the new\nsystem, so what is actually in here?\n\n* CLIF producers can mark values as needing to be present in a stack map if they\nare live across a safepoint in `cranelift-frontend`. This is the\n`FunctionBuilder::declare_needs_stack_map` method.\n\n* When we finalize the function we are building, we do a simple, single-pass\nliveness analysis to determine the set of GC references that are live at each\nsafepoint, and then we insert spills to explicit stack slots just before the\nsafepoint. We intentionally trade away the precision of a fixed-point liveness\nanalysis for the speed and simplicity of a single-pass implementation.\n\n* We annotate the safepoint with the metadata necessary to construct its\nassociated stack map. This is the new\n`cranelift_codegen::ir::DataFlowGraph::append_user_stack_map_entry` method and\nall that stuff.\n\n* These stack map entries are part of the CLIF and can be roundtripped through\nprinting and parsing CLIF.\n\n* Each stack map entry describes a GC-managed value that is on the stack and how\nto locate it: its type, the stack slot it is located within, and the offset\nwithin that stack slot where it resides. Different stack map entries for the\nsame safepoint may have different types or a different width from the target's\npointer.\n\nHere is what is *not* handled yet, and left for future follow up commits:\n\n* Lowering the stack map entries' locations from symbolic stack slot and offset\npairs to physical stack frame offsets after register allocation.\n\n* Coalescing and aggregating the safepoints and their raw stack map entries into\na compact PC-to-stack-map table during emission.\n\n* Supporting moving GCs. Right now we generate spills into stack slots for live\nGC references just before safepoints, but we don't reload the GC references from\nthe stack upon their next use after the safepoint. This involves rewriting uses\nof the old, spilled values which could be a little finicky, but we think we have\na good approach.\n\n* Port Wasmtime over to using this new stack maps system.\n\n* Removing the old stack map system, including `r{32,64}` from Cranelift and GC\nreference handling from `regalloc2`. (For the time being, the new system\ngenerally refers to \"user stack maps\" to disambiguate from the old system where\nit might otherwise be confusing.) If we wanted to remove the old system now,\nthat would require us to also port Wasmtime to the new system now, and we'd end\nup with a monolithic PR. Better to do this incrementally and temporarily have\nthe old and in-progress new system overlap for a short period of time.\n\nCo-authored-by: Trevor Elliott ","shortMessageHtmlLink":"Cranelift: Allow CLIF frontends to define their own stack maps (#8728)"}},{"before":"3a7cf36eb488de70dcc28a1fd7ea527e27ee19b8","after":null,"ref":"refs/heads/gh-readonly-queue/main/pr-8728-7a37e313d26b825d81425de67e33d775a0bc1114","pushedAt":"2024-06-06T18:41:27.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"}},{"before":null,"after":"3a7cf36eb488de70dcc28a1fd7ea527e27ee19b8","ref":"refs/heads/gh-readonly-queue/main/pr-8728-7a37e313d26b825d81425de67e33d775a0bc1114","pushedAt":"2024-06-06T18:26:58.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"},"commit":{"message":"Cranelift: Allow CLIF frontends to define their own stack maps (#8728)\n\nTracking GC references and producing stack maps is a significant amount of\ncomplexity in `regalloc2`.\n\nAt the same time, GC reference value types are pretty annoying to deal with in\nCranelift itself. We know our `r64` is \"actually\" just an `i64` pointer, and we\nwant to do `i64`-y things with it, such as an `iadd` to compute a derived\npointer, but `iadd` only takes integer types and not `r64`s. We investigated\nloosening that restriction and it was way too painful given the way that CLIF\ntype inference and its controlling type vars work. So to compute those derived\npointers, we have to first `bitcast` the `r64` into an `i64`. This is\nunfortunate in two ways. First, because of arcane interactions between register\nallocation constraints, stack maps, and ABIs this involves inserting unnecessary\nregister-to-register moves in our generated code which hurts binary size and\nperformance ever so slightly. Second, and much more seriously, this is a serious\nfootgun. If a GC reference isn't an `r64` right now, then it will not appear in\nstack maps, and failure to record a live GC reference in a stack map means that\nthe collector could reclaim the object while you are still using it, leading to\nuse-after-free bugs! Very bad. And the mid-end needs to know\n*not* to GVN these bitcasts or else we get similar bugs (see\nhttps://github.com/bytecodealliance/wasmtime/pull/8317).\n\nOverall GC references are a painful situation for us today.\n\nThis commit is the introduction of an alternative. (Note, though, that we aren't\nquite ready to remove the old stack maps infrastructure just yet.)\n\nInstead of preserving GC references all the way through the whole pipeline and\ncomputing live GC references and inserting spills at safepoints for stack maps\nall the way at the end of that pipeline in register allocation, the\nCLIF-producing frontend explicitly generates its own stack slots and spills for\nsafepoints. The only thing the rest of the compiler pipeline needs to know is\nthe metadata required to produce the stack map for the associated safepoint. We\ncan completely remove `r32` and `r64` from Cranelift and just use plain `i32`\nand `i64` values. Or `f64` if the runtime uses NaN-boxing, which the old stack\nmaps system did not support at all. Or 32-bit GC references on a 64-bit target,\nwhich was also not supported by the old system. Furthermore, we *cannot* get\nmiscompiles due to GVN'ing bitcasts that shouldn't be GVN'd because there aren't\nany bitcasts hiding GC references from stack maps anymore. And in the case of a\nmoving GC, we don't need to worry about the mid-end doing illegal code motion\nacross calls that could have triggered a GC that invalidated the moved GC\nreference because frontends will reload their GC references from the stack slots\nafter the call, and that loaded value simply isn't a candidate for GVN with the\nprevious version. We don't have to worry about those bugs by construction.\n\nSo everything gets a lot easier under this new system.\n\nBut this commit doesn't mean we are 100% done and ready to transition to the new\nsystem, so what is actually in here?\n\n* CLIF producers can mark values as needing to be present in a stack map if they\nare live across a safepoint in `cranelift-frontend`. This is the\n`FunctionBuilder::declare_needs_stack_map` method.\n\n* When we finalize the function we are building, we do a simple, single-pass\nliveness analysis to determine the set of GC references that are live at each\nsafepoint, and then we insert spills to explicit stack slots just before the\nsafepoint. We intentionally trade away the precision of a fixed-point liveness\nanalysis for the speed and simplicity of a single-pass implementation.\n\n* We annotate the safepoint with the metadata necessary to construct its\nassociated stack map. This is the new\n`cranelift_codegen::ir::DataFlowGraph::append_user_stack_map_entry` method and\nall that stuff.\n\n* These stack map entries are part of the CLIF and can be roundtripped through\nprinting and parsing CLIF.\n\n* Each stack map entry describes a GC-managed value that is on the stack and how\nto locate it: its type, the stack slot it is located within, and the offset\nwithin that stack slot where it resides. Different stack map entries for the\nsame safepoint may have different types or a different width from the target's\npointer.\n\nHere is what is *not* handled yet, and left for future follow up commits:\n\n* Lowering the stack map entries' locations from symbolic stack slot and offset\npairs to physical stack frame offsets after register allocation.\n\n* Coalescing and aggregating the safepoints and their raw stack map entries into\na compact PC-to-stack-map table during emission.\n\n* Supporting moving GCs. Right now we generate spills into stack slots for live\nGC references just before safepoints, but we don't reload the GC references from\nthe stack upon their next use after the safepoint. This involves rewriting uses\nof the old, spilled values which could be a little finicky, but we think we have\na good approach.\n\n* Port Wasmtime over to using this new stack maps system.\n\n* Removing the old stack map system, including `r{32,64}` from Cranelift and GC\nreference handling from `regalloc2`. (For the time being, the new system\ngenerally refers to \"user stack maps\" to disambiguate from the old system where\nit might otherwise be confusing.) If we wanted to remove the old system now,\nthat would require us to also port Wasmtime to the new system now, and we'd end\nup with a monolithic PR. Better to do this incrementally and temporarily have\nthe old and in-progress new system overlap for a short period of time.\n\nCo-authored-by: Trevor Elliott ","shortMessageHtmlLink":"Cranelift: Allow CLIF frontends to define their own stack maps (#8728)"}},{"before":"3ac8762098b760d849a26a0b6a6e6bdd767a2d8b","after":"161d46024dd43bb8227da3c0bd9df6f1407fe9fc","ref":"refs/heads/gh-pages","pushedAt":"2024-06-06T14:05:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deploying to gh-pages from @ bytecodealliance/wasmtime@7a37e313d26b825d81425de67e33d775a0bc1114 ๐","shortMessageHtmlLink":"Deploying to gh-pages from @ 7a37e31 ๐"}},{"before":"7a37e313d26b825d81425de67e33d775a0bc1114","after":null,"ref":"refs/heads/gh-readonly-queue/main/pr-8742-cdb59304c354d1357b9732fe6fd1189318437574","pushedAt":"2024-06-06T14:01:36.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"}},{"before":"cdb59304c354d1357b9732fe6fd1189318437574","after":"7a37e313d26b825d81425de67e33d775a0bc1114","ref":"refs/heads/main","pushedAt":"2024-06-06T14:01:35.000Z","pushType":"merge_queue_merge","commitsCount":1,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"},"commit":{"message":"Add a fuzz target for exercising bounds checks with various memory configs (#8742)","shortMessageHtmlLink":"Add a fuzz target for exercising bounds checks with various memory coโฆ"}},{"before":null,"after":"7a37e313d26b825d81425de67e33d775a0bc1114","ref":"refs/heads/gh-readonly-queue/main/pr-8742-cdb59304c354d1357b9732fe6fd1189318437574","pushedAt":"2024-06-06T13:47:34.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"},"commit":{"message":"Add a fuzz target for exercising bounds checks with various memory configs (#8742)","shortMessageHtmlLink":"Add a fuzz target for exercising bounds checks with various memory coโฆ"}},{"before":"b1ad4e46dd47c8b48b0f54c65587d9ce8f4a1691","after":"3ac8762098b760d849a26a0b6a6e6bdd767a2d8b","ref":"refs/heads/gh-pages","pushedAt":"2024-06-06T13:45:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deploying to gh-pages from @ bytecodealliance/wasmtime@cdb59304c354d1357b9732fe6fd1189318437574 ๐","shortMessageHtmlLink":"Deploying to gh-pages from @ cdb5930 ๐"}},{"before":"cdb59304c354d1357b9732fe6fd1189318437574","after":null,"ref":"refs/heads/gh-readonly-queue/main/pr-8750-28ee78b654e45cfa5837857d7880d8c40d571cb4","pushedAt":"2024-06-06T13:41:04.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"}},{"before":"28ee78b654e45cfa5837857d7880d8c40d571cb4","after":"cdb59304c354d1357b9732fe6fd1189318437574","ref":"refs/heads/main","pushedAt":"2024-06-06T13:41:03.000Z","pushType":"merge_queue_merge","commitsCount":1,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"},"commit":{"message":"Handle defined shared memories in dwarf processing (#8750)\n\nThis commit resolves an assert in the dwarf generating of core wasm\nmodules when the module has a defined linear memory which is flagged\n`shared`. This is represented slightly differently in the `VMContext`\nthan owned memories that aren't `shared`, and looks more like an\nimported memory. With support in #8740 it's now much easier to support\nthis.\n\nCloses #8652","shortMessageHtmlLink":"Handle defined shared memories in dwarf processing (#8750)"}},{"before":null,"after":"cdb59304c354d1357b9732fe6fd1189318437574","ref":"refs/heads/gh-readonly-queue/main/pr-8750-28ee78b654e45cfa5837857d7880d8c40d571cb4","pushedAt":"2024-06-06T13:26:30.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"github-merge-queue[bot]","name":null,"path":"/apps/github-merge-queue","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/9919?s=80&v=4"},"commit":{"message":"Handle defined shared memories in dwarf processing (#8750)\n\nThis commit resolves an assert in the dwarf generating of core wasm\nmodules when the module has a defined linear memory which is flagged\n`shared`. This is represented slightly differently in the `VMContext`\nthan owned memories that aren't `shared`, and looks more like an\nimported memory. With support in #8740 it's now much easier to support\nthis.\n\nCloses #8652","shortMessageHtmlLink":"Handle defined shared memories in dwarf processing (#8750)"}},{"before":"9f695788a92dc495fb80075d014da66a8a1da728","after":"0e93db7a74d7e3508b8ab96f7d2811901493edf6","ref":"refs/heads/release-22.0.0","pushedAt":"2024-06-06T01:49:40.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"alexcrichton","name":"Alex Crichton","path":"/alexcrichton","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/64996?s=80&v=4"},"commit":{"message":"Add release notes for 22.0.0 (#8751)\n\nBusy release!","shortMessageHtmlLink":"Add release notes for 22.0.0 (#8751)"}},{"before":"6ca290ccf6a1b59b5c52f90a1ac616f8343c6e37","after":"b1ad4e46dd47c8b48b0f54c65587d9ce8f4a1691","ref":"refs/heads/gh-pages","pushedAt":"2024-06-06T00:03:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deploying to gh-pages from @ bytecodealliance/wasmtime@28ee78b654e45cfa5837857d7880d8c40d571cb4 ๐","shortMessageHtmlLink":"Deploying to gh-pages from @ 28ee78b ๐"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEX6U-JgA","startCursor":null,"endCursor":null}},"title":"Activity ยท bytecodealliance/wasmtime"}