This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Use dummy debug info in Emscripten SjLj
ClosedPublic

Authored by aheejin on Apr 9 2020, 2:27 AM.

Details

Summary

D74269 added debug info to newly created instructions, including calls
to malloc and free, by taking debug info from existing instructions
around, whose debug info may or may not be empty.

But there are cases debug info is required by the IR verifier: when both
the caller and the callee functions have DISubprograms, meaning we
already have declarations to malloc or free with a DISubprogram
attached, newly created calls to malloc and free should have
non-empty debug info. This patch creates a non-empty dummy debug info in
this case to those calls to make the IR verifier pass.

Fixes https://bugs.llvm.org/show_bug.cgi?id=45461.

Diff Detail

Event Timeline

aheejin created this revision.Apr 9 2020, 2:27 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 9 2020, 2:27 AM
aheejin updated this revision to Diff 256221.Apr 9 2020, 2:36 AM

Small fix

aheejin marked an inline comment as done.Apr 9 2020, 2:37 AM
aheejin added inline comments.
llvm/test/CodeGen/WebAssembly/lower-em-sjlj-debuginfo.ll
11

This function was just moved from lower-em-sjlj.ll.

aheejin edited the summary of this revision. (Show Details)Apr 9 2020, 3:26 AM

It just occurred to me, could we just mark the calls as non-inlineable? I assume we won't be running the inliner after this anyway. Or is that a property of the called function and not the callsite?
Anyway this approach seems ok to me too. It seems to me that there are other places we inject calls to runtime functions too; but I guess the others are mostly to imported functions and don't have this problem?

It just occurred to me, could we just mark the calls as non-inlineable? I assume we won't be running the inliner after this anyway. Or is that a property of the called function and not the callsite?

As you can see here, even if the error message says "inlinable call site blah blah", the condition being checked is not something about properties of the call instruction or callsite; it only checks three things:

  • Is there a called function? (Not sure when this can be false though)
  • Is the current caller function has a DISubprogram?
  • Is the callee function has a DISubprogram?

So the reason it was OK so far after D74269 was, even though the caller had a DISubprogram, the callees (malloc and free) didn't have one. But it turned out there can be cases in which declarations of malloc and free can have DISubprogram too. So it is not possible to make this function non-inlinable, because the conditions don't really check them anyway.

Anyway this approach seems ok to me too. It seems to me that there are other places we inject calls to runtime functions too; but I guess the others are mostly to imported functions and don't have this problem?

Yes, all other functions we inject calls to in this pass are imported.

dschuff accepted this revision.Apr 9 2020, 1:48 PM

LGTM
(I'll bet Call.getCalledFunction() returns nullptr if it's an indirect call)

This revision is now accepted and ready to land.Apr 9 2020, 1:48 PM
This revision was automatically updated to reflect the committed changes.