Infix operators in the text format? about wasmtime

[phase]

I don't think this is something than an IR should add. This adds needless complexity that compiler writers don't need when working with IR. It seems odd that we would want to obfuscate the registers when that's exactly what a compiler writer would want to see.

[Hyperion101010]

Hi there sunfishcode can i work on this issue, i am new to contributing for open source.
I found compiler design interesting in our class and decided to contribute for same.
I have contributed for mozilla ,some patches in past few months, so i know the procedure of adding patches :)

[Hyperion101010]

If i am not wrong, web assembly will be used by high level language programmers(web developers) that use js in their day-to-day work. So the code must be easy to read. Moreover if we are thinking about games,etc developers they code in C++ which is again not assembly.

[sunfishcode]

Hello! This is a good issue to work on, though to be clear, this is about the text format for Cranelift IR, not for WebAssembly itself, so it won't be visible to most developers unless they use compiler-explorer-type tools to look at the compiler IR as its compiling their code.

One of the big tasks here will be to implement infix expression parsing. My high-level idea here is that we can use an operator precedence parser. Do you think that sounds like a good approach?

[Hyperion101010]

Let's discuss on irc !
I am very excited to start working on this issue

[Hyperion101010]

hi sunfish what tool are we going to use here ? I can practice them to get working on this issue !

[sunfishcode]

My rough idea here is that a hand-written operator precedence parser would work well, since the rest of the parser is also hand-written. However, I'm open to other suggestions here.

[Hyperion101010]

As far as i know it is just a debug feature for programmer .Using this he can understand wasm code more clearly like high level code .

[sunfishcode]

@phase When I see something like "add v3, v4" in an IR dump before register allocation, most often my next question is "what defined r3 and/or r4?" and next most often my next question is "what else is using v3 or v4?" The infix notation proposed here would make it easier to answer both those questions in many common cases.

If we make this optional so that people don't have to see it when they don't want to, and if we disable it during and after register allocation, it seems like it could make the IR much more readable in many common cases.

Ultimately, I can't say for sure if this will be great, but it has potential :-).

[bnjbvr]

@phase When I see something like "add v3, v4" in an IR dump before register allocation, most often my next question is "what defined r3 and/or r4?" and next most often my next question is "what else is using v3 or v4?" The infix notation proposed here would make it easier to answer both those questions in many common cases.

This made me think that an alternative / a nice addition to solve this particular problem would be to implement the language server protocol for CLIF. Then, we get "jump to definition" and "see all uses" for free in all the IDEs that have LSP addons (Visual Code, Sublime Text, Vim, etc.). Totally over-engineering to solve such a use case, but a fun small, self-contained project to write, and this could reuse a lot of code from the CLIF parsing infrastructure.

[cfallin]

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.