Read and write label names from the name section by vouillon · Pull Request #9166 · WebAssembly/binaryen

vouillon · 2026-09-28T17:36:24Z

This is the only section of the Extended Name Section proposal which is currently not handled.

Read label names, and use the names when building the IR. Blocks and loops can hold names directly. `if`, `try` and `try_table` cannot, so for them the name is only a hint: we use it when a branch to the scope means we have to create a wrapper block anyhow, and otherwise drop it, so that reading these names never changes the shape of the IR.

Write the label subsection (id 3) next to the function and local names when debug info is enabled. Only explicit names are written: the ones that came from the text format, from the name section, or through the C API, and not the ones we generate ourselves. Functions therefore gain an `explicitLabelNames` set, filled by IRBuilder when a label comes from outside rather than from makeFresh(). Keeping this next to `localNames` and `debugLocations` rather than on the expressions themselves is how the rest of our debug info is stored, and it has two advantages: ExpressionAnalyzer never sees it, so two otherwise-identical blocks cannot stop comparing equal because of debug info; and since label names are unique within a function, it keeps identifying the right labels as optimizations replace the expressions that carry them.

kripken · 2026-09-28T21:25:47Z

  void writeExpression(Expression* curr);
  void writeFunctions();
+  void noteLabelNames(Function* func,
+                      std::vector<std::pair<Index, Name>>& labelNames);


This is a helper, not one of the core write* methods, so perhaps let's move it to a less prominent place? (maybe around line 1585, the end of the class) Also, it could use a comment as to what it does and what the parameters mean.

kripken · 2026-09-28T23:57:35Z

-  ;; CHECK-NEXT:        (block $label
-  ;; CHECK-NEXT:         (try $try1
+  ;; CHECK-NEXT:        (block $try1
+  ;; CHECK-NEXT:         (try


Why are there changes in this file? I don't seem to see it writing a binary, so the names section changes should not apply..?

I have made some changes in the IRBuilder to better place labels. For try, we have the choice of putting the label on the wrapper block (as is done for if and try_table) or on the try itself. When there are only branches targeting it (no delegate or rethrow), I think it makes more sense to put the label on the wrapper block: that's why we now have (block $try1), and (br_if $try1) instead of (br_if $label), in this file. Since the IRBuilder is shared between the binary and the text parser, this impacts both.

I can remove this change from this PR and always put the label on the try if you prefer.

I see, thanks. Please move from it from this PR, then, to keep things simple, and that other PR nice and focused. This is already a large (but useful!) change.

I have removed the change from the PR.

kripken · 2026-09-30T17:56:58Z

+      // end up needing a label anyhow.
+      auto name = getNextLabelName();
+      auto result = builder.makeIf(Name(), getBlockType());
+      builder.setScopeNameHint(name);


makeIf accepts a name, and at a glance, seems to use it as best it can. Why can we not pass in the name here directly, rather than sending Name() and then calling setScopeNameHint? (Should makeIf call that method..?)

Passing a name to makeIf inserts a wrapper block to hold the label. So, the IR would change depending on whether we read the name section or not.

If we change makeIf to treat the label as a hint, this will impact the text parser: unused labels will get dropped.

I see, thanks. @tlively should we change the parser to do this? (@vouillon 's last sentence)

We can consider this independently of this PR though.

I'd be ok with makeIf treating the passed label as a hint. I don't see why we might want to synthesize a block with an unused label just because the label was present in the input.

I can do that in a follow-up PR.

kripken · 2026-09-30T22:38:50Z

      if (!scope.label) {
        scope.label = makeFresh(label);
      }
+      scope.labelExplicit = true;


Don't we push scopes in various situations? Why is the label here always explicit?

Indeed! Outlining calls visit functions, which push scopes, based on existing expressions whose labels may be generated internally. I have moved the marking to the make functions which are only called from the parsers.

kripken · 2026-10-01T16:15:50Z

+   (do (nop))
+   (catch_all (nop))
+  )
+  ;; A branch to a try needs a wrapper block, which takes the name.


It doesn't look like this is what is in the output? I see

(block $block (try $branched-try

(the block didn't "take" the name - unless I don't understand what "take" means here)

Right. The comment was stale.

kripken · 2026-10-01T22:47:26Z

@@ -0,0 +1,292 @@
+;; NOTE: Assertions have been generated by update_lit_checks.py --all-items and should not be edited.
+;; Test that we write explicit label names to the name section with -g, and
+;; that we do not write the names we generate ourselves.


I am not immediately clear on how to verify this in the test below. Perhaps annotate places with "here a name will be generated ourselves, and it will [..]" (the last part is what confuses me: even if we generate it ourselves, we generated it for a reason, so it will show up in the output? so how can we tell what is in the name section or not, just by reading the reloaded wat..?)

This file now only checks that the names are preserved.

In test/lit/binary/label-names-generated.wast, one can see that the label $__inlined_func$callee appears in the text output but not after a round trip through the binary.

I'm not sure how to do better, since we don't have any easy way to print the name section.

How about directly inspecting the name section? We can write a unit test in python that parses the first few bytes of the name section, just enough to see there is only 1 name, and grep finds it in the wasm? (that would prove all other names are not in there)

in node, .customSection is an easy way to get the section bytes, so that is another option.

I think leaving comments in this file about the generated names (or combining the test files and/or having a third check prefix showing the directly emitted wat with generated names here) would be better than adding a new python unit test or using node.

tlively · 2026-10-02T23:58:31Z

+;; RUN: wasm-dis %t.nodebug.wasm -all -o - | filecheck %s --check-prefix=CHECK-BIN-NODEBUG
+
+(module
+ ;; INLINE:      (type $0 (func (param i32) (result i32)))


It looks like the INLINE checks might be stale; they don't have a corresponding RUN line.

vouillon requested a review from a team as a code owner September 28, 2026 17:36

vouillon requested review from kripken and removed request for a team September 28, 2026 17:36

vouillon force-pushed the label-names branch from cb552ac to 7ddcda1 Compare September 28, 2026 18:13

vouillon force-pushed the label-names branch from 7ddcda1 to 01f2737 Compare September 28, 2026 19:41

Changes

198adc7

kripken reviewed Sep 28, 2026

View reviewed changes

vouillon added 4 commits September 29, 2026 12:01

Move helper functions at a more appropriate place

ac23c0e

Preserve labels on try

281ea7e

Preserve try labels coming from the name section

4b7f186

Keep main's label placement for try

e6bde55

kripken reviewed Sep 30, 2026

View reviewed changes

Fix explicit labels

6717f35

kripken reviewed Oct 1, 2026

View reviewed changes

Fix outdated comments about try label placement

79e8949

kripken reviewed Oct 1, 2026

View reviewed changes

Test generated label names in their own file

2b4aad2

tlively reviewed Oct 2, 2026

View reviewed changes

Conversation

vouillon commented Sep 28, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kripken Sep 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

kripken Sep 29, 2026 •

edited

Loading