Wasmtime GitHub notifications bot (Mar 28 2026 at 01:16): Wasmtime GitHub notifications bot (Mar 28 2026 at 01:16):vxpm opened issue #12863:
Being able to attribute textual labels to IR values that would then be shown in the textual IR representation generated by
displaywould greatly benefit the readability of CLIR.This could easily be implemented outside of cranelift, but not without rewriting pretty much all of the machinery in
cranelift_codegen::write, which feels like a waste.Implementation should be as easy as a
SecondaryMap<Value, String>, for example.
Wasmtime GitHub notifications bot (Mar 28 2026 at 14:29):cfallin commented on issue #12863:
We could embed a value-to-string map in Cranelift's data structures (which, you're right, is possible, and not unreasonable in terms of code complexity) but that would still carry some overhead, and more importantly, if the embedder already has these names in some other form (e.g. as part of larger metadata or something) it would require duplication/copying. IMHO it would be slightly nicer to (optionally) take a closure when printing IR that allows the embedder to provide an
Option<&str>for aValue. We could put this inside aDisplay-implementing wrapper struct around theFunction. What do you think?
Wasmtime GitHub notifications bot (Mar 28 2026 at 15:24):vxpm commented on issue #12863:
Yes, that sounds good! While at it, it would be great to attribute these labels to other entities, too, such as blocks, srclocs, instructions, etc. Right now i use
srclocs to represent a guest instruction in lazuli's JIT as the only sort of metadata I can show on display - having these would be wonderful.Is this something you cranelift mantainers are willing to implement right now? If not, I can try my hand at it - just give me some guidance on how you'd like to see it implemented and I'll do it.
Wasmtime GitHub notifications bot (Mar 28 2026 at 15:25):vxpm edited a comment on issue #12863:
Yes, that sounds good! While at it, it would be great to attribute these labels to other entities, too, such as blocks, srclocs, instructions, etc. Right now I use
srclocs to represent a guest instruction in lazuli's JIT as the only sort of metadata I can show on display - having these would be wonderful.Is this something you cranelift mantainers are willing to implement right now? If not, I can try my hand at it - just give me some guidance on how you'd like to see it implemented and I'll do it.
Wasmtime GitHub notifications bot (Mar 29 2026 at 00:06):cfallin commented on issue #12863:
Is this something you cranelift mantainers are willing to implement right now? If not, I can try my hand at it - just give me some guidance on how you'd like to see it implemented and I'll do it.
In general we are short on time now and are not free to respond to new feature requests. But I'd be happy to review a PR if you are willing to work on this! I think what I described above is more or less what I'd expect: a newtype struct that wraps a
Functionand carries a closure (or perhaps a trait, if you want to give optional names to all entities?) then prints with the names it is given, or the default ifNone. We should push the existing printing through this path with a no-op trait rather than duplicate printing logic. We'll want to carefully document that if this feature is used, the resulting text is not round-trippable (it becomes a custom format rather than Cranelift-parseable CLIF).
Wasmtime GitHub notifications bot (Apr 05 2026 at 10:36):kamirr commented on issue #12863:
it becomes a custom format rather than Cranelift-parseable CLIF
Wouldn't be able to keep that by printing the labels as CLIF comments, like SSA constants?
Wasmtime GitHub notifications bot (Apr 05 2026 at 10:37):kamirr edited a comment on issue #12863:
it becomes a custom format rather than Cranelift-parseable CLIF
Wouldn't we be able to keep that by printing the labels as CLIF comments, like SSA constants?
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:58):cfallin commented on issue #12863:
@kamirr sure, that's another option; either seems reasonable enough to me.
Last updated: Apr 12 2026 at 23:10 UTC