Stream: git-cranelift

Topic: cranelift / Issue #1102 Allow extending InstBuilder with ...


view this post on Zulip GitHub (Feb 28 2020 at 23:27):

alexcrichton transferred Issue #1102:

This is a continuation from https://github.com/CraneStation/cranelift/pull/921 which was a WIP showing demo code. It's usually better to discuss scope and advantages in issues, so opening one.

Currently, the best, secure way to create the Cranelift IR is to go through InstBuilder, a trait implemented by several structures. If you've manipulated Cranelift, there are chances you've interacted with it: pos.ins() or pos.replace(inst) returns an InstBuilder.

It is doing the minimal job at the moment: creating the instruction format, filling it with data, putting it into the DFG, and returning the result SSA values.

This issue proposes adding the possibility to extend the InstBuilder with more advanced behaviors.

New opportunities

Constant folding

For instance:

let v1 = pos.ins().iconst(I32, 42);
let v2 = pos.ins().uextend(I64, v1);

currently results in two IR nodes, while it could just be one with pos.ins().iconst(I64, 42). This would mean that the v1 value may be dead after the conversion, in which case DCE could remove it. If an InstBuilder is used after DCE happened, it also means these dead nodes can stay around forever.

(You might interject that Cranelift IR is a low-level compiler and that constant propagation should have been performed by the compiler. In most cases, you'd be right, but translating from an IR to another introduces redundancies / new folding opportunities that the initial IR didn't have. I've certainly observed this when translating from wasm to CLIF IR with cranelift-wasm.)

Pattern-match some sequences of IR nodes into other nodes

Mostly what simple_preopt does, like converting iadd(iconst(C), x) into iadd_imm(x, C), or folding together series of iadd_imm(x, C). At the limit, we could even remove simple-preopt entirely, or move it into the cranelift-preopt crate. Maybe postop could also be integrated as part of these custom methods.

Same caveat about dead nodes.

Fix some incorrect behaviors

Arguably, things like https://github.com/CraneStation/cranelift/issues/815 could be fixed as part of a custom builder method. Would be better to fix it in the plain trait method, though.

Proposed implementation

Drawbacks / Caveats

Benefits

Curious to hear people's thoughts about this!


Last updated: Dec 23 2024 at 13:07 UTC