[PATCH] D52837: [WebAssembly] Ignore DBG_VALUE in WebAssemblyCFGStacify pass when looking for block start

[Heejin Ahn via Phabricator via llvm-commits]

aheejin added a comment.

I'm sorry, it turns out this MIR test doesn't work for now, because the target-specific state in the target-specific MachineFunctionInfo subclasses isn’t serialized at the moment <https://llvm.org/docs/MIRLangRef.html#limitations>. Continuing our discussion from IRC, the reason why this MIR test succeeds even without your patch is, `MFI.isVRegStackified(Reg)` <https://github.com/llvm-mirror/llvm/blob/f590076c467cd7ea2a349c81ae02bafe71591496/lib/Target/WebAssembly/WebAssemblyUtilities.cpp#L102> in `WebAssembly::isChild` <https://github.com/llvm-mirror/llvm/blob/f590076c467cd7ea2a349c81ae02bafe71591496/lib/Target/WebAssembly/WebAssemblyUtilities.cpp#L93-L103> always returns false, because `VRegStackified` <https://github.com/llvm-mirror/llvm/blob/f590076c467cd7ea2a349c81ae02bafe71591496/lib/Target/WebAssembly/WebAssemblyMachineFunctionInfo.h#L38-L44> variable accessed in `WebAssemblyFunctionInfo::isVRegStackified` <https://github.com/llvm-mirror/llvm/blob/f590076c467cd7ea2a349c81ae02bafe71591496/lib/Target/WebAssembly/WebAssemblyMachineFunctionInfo.h#L96-L101> is now empty. This is supposed to be populated in RegStackify pass, but MIR file cannot serialize information in target-dependent subclasses of `MachineFunctionInfo`, so we can't pass that info to CFGStackify here.

The serialization of target-dependent `MachineFunctionInfo` is something I'd like to implement someday for my own purpose unless someone does that by then, but I don't think this patch should be blocked on it anyway. One way we possibly still do an MIR test is to pass multiple passes to `llc`. AFAIK you can pass multiple `-run-pass` flags to `llc`, like `llc -run-pass wasm-reg-stackify -run-pass wasm-reg-coloring ...`. Maybe we can start from mir just before the RegStackify pass and make llc run all passes from RegStackify to CFGStackify. I think it's worth trying. If this fails for some other reason, we can bring back .ll test case...

Either way,  could you minimize the test case and elaborate little more on 'before' and 'after' results? I'm sorry for the hassle. Thank you.


Repository:
  rL LLVM

https://reviews.llvm.org/D52837