This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Clear frame base vreg in explicit-locals when stack pointer is dead
ClosedPublic

Authored by dschuff on Mar 25 2020, 10:36 AM.

Details

Summary

Having an alloca in a function causes the stack pointer to be generated in the prolog, but if it's unused other than for debug info, explicit-locals will drop it and not allocate a local. In this case we need to reset the FrameBaseVreg.

Diff Detail

Event Timeline

dschuff created this revision.Mar 25 2020, 10:36 AM
dschuff retitled this revision from [WIP] Clear frame base vreg when it's dead to Clear frame base vreg when it's dead.Mar 25 2020, 3:19 PM
dschuff edited the summary of this revision. (Show Details)
dschuff retitled this revision from Clear frame base vreg when it's dead to [WebAssembly] Clear frame base vreg in explicit-locals when stack pointer is dead.Mar 25 2020, 3:20 PM
dschuff added a reviewer: aardappel.EditedMar 25 2020, 3:33 PM

the IR to reproduce this is trivial but i'm still trying to reduce the debug info in the test. Basically this:

define hidden %"struct.foo"* @"foo"() #1 !dbg !2 {
fentry:
  %0 = alloca %"struct.bar", align 1
  call void @llvm.dbg.declare(metadata %"struct.bar"* %0, metadata !21513, metadata !DIExpression()), !dbg !21514
  ret %"struct.bar"* @"globl_", !dbg !21515
}

...plus just enough debug info to cause generation of a CU and subprogram with a frame base.

But this came up in the openCV demo so it must not be that uncommon.

(FTR, the failure mode is the same assertion in MFI::getFrameBaseLocal() that we saw before)

aardappel accepted this revision.Mar 25 2020, 4:05 PM

You mean alloca as in the C function, not as in the LLVM concept, I guess.

And yes, this is all very brittle code, having to potentially call these functions upon each register change. I wonder if there's a better way, like making the concept of FrameBase be a flag on a register, such that when the register gets deleted it is automatic. But that would probably still require special purpose when renumbered, when lowered to a local, etc etc.

This revision is now accepted and ready to land.Mar 25 2020, 4:05 PM

No I mean alloca as in the LLVM instruction. Just having an address-taken local in C is enough to cause an alloca in the IR.

And yeah you are right, I think it would still require the same ways to deal with it.
I think a possible alternative would be to go back to modeling SP as a physical register, and exempting it from the code that touches vregs. That would have some complications of its own (and probably result in slightly worse code in some cases), but may or may not be cleaner.

Even in this case the final output code has a prolog that calculates a value for SP but then immediately drops it because it's unused. This CL keeps it from crashing but clearly we should do better and either not emit or optimize away the prolog entirely.

This revision was automatically updated to reflect the committed changes.