I think it is the CoalesceLocals pass that pollutes the unused block removal by introducing the local.tee instruction, and the local.tee hinders the analysis of the condition of first br_if.

The direct solution I think is handling local.tee in optimizeBoolean. Is there any better way?

I think the natural place to fix this is in RemoveUnusedBrs, which aims to remove branches we don't need. If the fallthrough of the condition is constant, we can infer how the branch happens, and apply that (keeping dropped children as needed). The specific place there would be to add a visitBreak in the FinalOptimizer class.

Yes, it's more natural to fix in the RemoveUnusedBrs pass.

By the way, I am also curious about the root cause, why cannot optimize this pattern:

 (func $_start
  (local $0 i32)
  (block $block
   (br_if $block   <----------------  item1
     (local.tee $0
     (i32.const 1)
    )
   )
   (br_if $block  <---------------- item2
    (i32.load
     (i32.const 0)
    )
   )
   (local.set $0 <--------------- item3
    (i32.const 0)
   )
  )
  (i32.store <------------------- item4
   (i32.const 0)
   (local.get $0)
  )
 )

Above is the minimal code snippet which can trigger the missed optimization, and removing any of the item above won't trigger. Why? Does the mixed cases difficult to analyze?

BTW, I already understand the benefits of optimizing on AST IR (e.g., direct, language-specified) from

1. Future of Binaryen in a stack machine world? #663
2. Why compile to WebAssembly using Binaryen?

However, it seems wasm-opt suffer a lot from side-effect code. For example:

• ASTs with side effects often require manually using getDroppedChildrenAndAppend (while in LLVM it doesn't bother to)
• Mixed cases are hard to analyze (example above)

All of these lead to missed optimizations. In LLVM, we don’t have to worry about so many side-effect ordering issues — right? How can we understand the pros and especially the cons of language-specific IR. Thank you.

(Sorry for accidentally closed this issue... could you please reopen it)

I'm not sure what you mean by "mixed cases"? What is the problem there aside from not handling the local.tee properly?

All of these lead to missed optimizations. In LLVM, we don’t have to worry about so many side-effect ordering issues — right?

Yes, this is a tradeoff. Binaryen tries to be very close to wasm, and that has some downsides, like anything can be an expression with side effects.

The general idea in the past was that we'd handle side effects like that by "flattening" the code, as -O4 does, using --flatten, which avoids nested side effects. However, as wasm grew, flattening code like that became harder (e.g. GC and exceptions add more branches, pops off the stack, etc., which flatten doesn't model well). So it is better not to rely on flattening now.

Another idea in the past was to use a "dataflow" IR which is in SSA form, like LLVM, see

https://github.com/WebAssembly/binaryen/blob/main/src/dataflow/node.h

That worked well enough for integration with Souper, but it does add overhead to convert the IR like that.

Overall, it is better to add getDroppedChildrenAndAppend in relevant places, I think. There is probably a long list of missing places, though also I think we've covered the great majority of common cases already.

As for tradeoffs, all these downsides should be compared to the benefit of optimizing on an IR that matches wasm closely. By doing that we don't miss out on low-level opportunities. LLVM, for example, has to optimize not just LLVM IR but also the backend codegen after lowering (e.g. after turning SSA into concrete registers, new opportunities can arise).

Thanks for careful explanation.

I'm not sure what you mean by "mixed cases"? What is the problem there aside from not handling the local.tee properly?

Well, some misunderstandings in my question, but now I understand now.