Stream: git-wasmtime

Topic: wasmtime / issue #1090 Move the cranelift-preopt crate co...


view this post on Zulip Wasmtime GitHub notifications bot (May 04 2022 at 20:55):

cfallin labeled issue #1090:

I think cranelift-preopt was separated from cranelift-codegen because we assume that, in general, the input IR has been generated by an optimizing compiler (namely, one that ran constant folding). This being said, in our use case, when translating wasm to clif, we're likely to introduce redundancies and constant-foldable instructions that aren't obvious to catch (because we're operating on one wasm binary opcode at a time). There was also another instance of constant-foldable operations being emitted by legalization recently.

In principle, every pass that takes IR and augments it (by adding more IR nodes) is likely to introduce redundancies / constant-foldable instructions. I'd like someone to get more data on this, but how would people feel about putting the cranelift-preopt constant folding facilities into codegen instead?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 26 2023 at 18:59):

bjorn3 commented on issue #1090:

This could be merged into the egraph impl, right?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 26 2023 at 19:23):

jameysharp commented on issue #1090:

I didn't know cranelift-preopt existed. Wow. Looks like 1) most of it is covered by cprop.isle in the egraph work already; 2) the cranelift-preopt rules for udiv are wrong in two ways I think?

We should add appropriate floating-point rules to cprop.isle, but even without that I'd be inclined to just delete this crate, unless somebody has objections.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 26 2023 at 19:46):

bjorn3 commented on issue #1090:

No objections from me. I don't use it in cg_clif.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 26 2023 at 21:32):

jameysharp closed issue #1090:

I think cranelift-preopt was separated from cranelift-codegen because we assume that, in general, the input IR has been generated by an optimizing compiler (namely, one that ran constant folding). This being said, in our use case, when translating wasm to clif, we're likely to introduce redundancies and constant-foldable instructions that aren't obvious to catch (because we're operating on one wasm binary opcode at a time). There was also another instance of constant-foldable operations being emitted by legalization recently.

In principle, every pass that takes IR and augments it (by adding more IR nodes) is likely to introduce redundancies / constant-foldable instructions. I'd like someone to get more data on this, but how would people feel about putting the cranelift-preopt constant folding facilities into codegen instead?


Last updated: Nov 22 2024 at 16:03 UTC