[llvm] [WebAssembly] Add RefTypeMem2Local pass (PR #81965)

[Heejin Ahn via llvm-commits]

aheejin wrote:

Sorry for the late reply! I was OOO for a while.

> Would it be beneficial to expand this pass to all types (where possible), not just reference types?
> 
> The main argument against unconditionally running `mem2reg` was that it causes debug info to be handled differently or lost. AFAIK this should not be an issue here, since we are keeping all the loads and stores the same and just modifying the allocas.

Correct me if I'm mistaken. `alloca`s debug information is usually tracked with `llvm.dbg.declare`, and this `llvm.dbg.declare` info is later stored in the [MMI table](https://github.com/llvm/llvm-project/blob/004c1972b4585fe8051814ceb6c6cdbf3cb62290/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h#L200-L202). So this debug info is handled differently from `llvm.dbg.value`, which is lowered down to `DBG_VALUE` mir instruction.

But it looks the MMI table only works with memory, so currently the `alloca`s/`store`s/`load`s that are lowered down to `local.set`s/`local.get`s seem to lose their debug info, which we someday should fix. For example, if I add `llvm.dbg.declare` after `alloca`s in this PR's test case, like this:
```ll
  %alloc.externref = alloca ptr addrspace(10), align 1, !dbg !17                 
  tail call void @llvm.dbg.declare(metadata ptr %alloc.externref, metadata !9, metadata !DIExpression()), !dbg !17
  ...
  %alloc.funcref = alloca ptr addrspace(20), align 1, !dbg !22                   
  tail call void @llvm.dbg.declare(metadata ptr %alloc.funcref, metadata !14, metadata !DIExpression()), !dbg !22
  ...
  %alloc.i32 = alloca i32, align 4, !dbg !33                                     
  tail call void @llvm.dbg.declare(metadata ptr %alloc.i32, metadata !30, metadata !DIExpression()), !dbg !33
```
and compile it to an object file and using `llvm-dwarfdump` to see the info, reftype `alloca`s lose their debug info, while the pod i32 `alloca` has its debug info retained using the MMI table:
```
0x0000003e:     DW_TAG_variable
                  DW_AT_location        (DW_OP_fbreg +12)
                  DW_AT_decl_file       ("/ref-type-mem2local.ll")
                  ...
```

So I'm not sure what you mean by that debug info is not an issue here, because it looks debug info is lost. I think what we should do is to generate appropriate `DBG_VALUE`  instructions in the iSel to match those newly generated `local.get`/`local.set`s, but still, unlike the MMI table info, `DBG_VALUE` info can be lost going through backend transformations. (Even if we disable optimizations, there are still some backend passes we need to run)

Given that reference type variables are supposedly rare, I don't think this loss of debug info would affect the debug info coverage a lot yet, but doing the same thing for all types will likely delete all variable debug info at this point. Even if we add the `DBG_VALUE` transfer, because that info is not as reliable as the MMI table, they can still be lost.

> In fact, this would make debugging easier (especially in situations where DWARF debug info is not available), as well as produce simpler and faster code in unoptimized builds.

Why would it make debugging easier? I also don't understand what situation you mean by "where DWARF debug info is not available", because I've been assuming DWARF info when talking about debug info in LLVM. Are there other framework we use to cover variable debug info? 

Also I think it's OK for unoptimized builds to be slow.

https://github.com/llvm/llvm-project/pull/81965