This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo][InstrRef] Handle llvm.frameaddress intrinsics gracefully
ClosedPublic

Authored by jmorse on Jul 23 2021, 6:17 AM.

Details

Summary

When working out which instruction defines a value, the instruction-referencing variable location code has a few special cases for physical registers:

  • Arguments are never defined by instructions,
  • Constant physical registers always read the same value and are never def'd.

This patch adds a third case for the llvm.frameaddress intrinsics: you can read the framepointer in any block if you so choose, and use it as a variable location, as shown in the attached patch.

This rather violates one of the assumptions behind instruction referencing, that llvm-ir shouldn't be able to read from an arbitrary register at some arbitrary point in the program. The solution for now is to just emit a DBG_PHI that reads the register value: this works, but if we wanted to do something clever with DBG_PHIs in the future then this would probably get in the way. As it stands, this patch avoids a crash.

Diff Detail

Event Timeline

jmorse created this revision.Jul 23 2021, 6:17 AM
jmorse requested review of this revision.Jul 23 2021, 6:17 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 23 2021, 6:17 AM
Orlando accepted this revision.Jul 26 2021, 6:27 AM

LGTM

llvm/lib/CodeGen/MachineFunction.cpp
1149

The empty if body looks a little odd but makes sense to me. I don't think you need the ; though, unless this is to match prior art? No strong opinion.

llvm/test/DebugInfo/X86/instr-ref-framereg-read.ll
8–9

Why is it important to check outside of the entry block (it might be worth adding to the comment in the test too, ymmv)?

26

nit: there seems to be some wobbly indentation above

This revision is now accepted and ready to land.Jul 26 2021, 6:27 AM
jmorse added inline comments.Jul 27 2021, 5:16 AM
llvm/test/DebugInfo/X86/instr-ref-framereg-read.ll
8–9

If the frame pointer is read in the entry block, there's a chance that it'll be interpreted as a function argument (i.e. a register not otherwise defined in the block). Depending on how the frame setup works, there might be instructions that def the frame register anyway in the entry block -- which wouldn't expose the problem this patch fixes.

(Folding this explanation into landing patch)

This revision was landed with ongoing or failed builds.Jul 27 2021, 5:45 AM
This revision was automatically updated to reflect the committed changes.