Stream: git-wasmtime

Topic: wasmtime / issue #1051 Infix operators in the text format?

Wasmtime GitHub notifications bot (May 04 2022 at 20:42):

cfallin commented on issue #1051:

I'm doing some issue gardening and came across this. I think that I agree with the above arguments that this is not very "IR-like": in a sense it privileges certain operations (add, multiply, ...) and allows them to be written in a special syntax that looks like something other than a linear sequence of instructions. Since the underlying abstraction is that linear sequence of instructions, IMHO it would be better for the notation to remain closer to that.

There are also issues about round-tripping: do we represent how the expression was written in the parsed input and try to reproduce that when printing the CLIF back out? Or do we try to maximally use an expression syntax? It's simpler if we always, unconditionally, print one instruction per line, in instruction order.

So I'll go ahead and close this, given the discussion has quiesced, but if someone wants to make a renewed push for it, please feel free to do so.

Wasmtime GitHub notifications bot (May 04 2022 at 20:42):

cfallin closed issue #1051:

Currently, cranelift IR is always printed with one instruction per line, eg.:

function %foo(i32, i32, i32) -> i32 {
ebb0(v0: i32, v1: i32, v2:i32):
    v3 = imul v0, v1
    v4 = iadd v3, v2
    return v4
}

What if we introduced some simple syntax sugar for instructions with only one use? It'd be in addition to the existing syntax. We could then (optionally) print that same code like this:

function %foo(i32, i32, i32) -> i32 {
ebb0(v0: i32, v1: i32, v2:i32):
    return v0 * v1 + v2
}

That would be much easier to read in many cases, which is of potential interest to cranelift developers, but also to cranelift users looking to understand how cranelift is compiling their code.

This also might make it even more interesting to switch to // comments (#471).

There's some ambiguity with syntax like v0 + 1, but I think we can resolve it by saying that we always use the _imm instruction when possible rather than emitting an iconst

And there's the question if value numbers for the intermediate values. My rough idea is that they'd just always use the next available value number.

There are other issues to consider too, such as printing srclocs and instruction encodings. But I think we could find reasonable ways to make these work. The main question is, is this idea worth pursuing?

Last updated: Nov 22 2024 at 16:03 UTC