This is an archive of the discontinued LLVM Phabricator instance.

[Assignment Tracking][3/*] Add DIAssignID metadata boilerplate
ClosedPublic

Authored by Orlando on Aug 19 2022, 6:14 AM.

Details

Summary

The Assignment Tracking debug-info feature is outlined in this RFC. This first series of patches adds documentation, the changes necessary to start emitting and using the new metadata, and updates clang with an option to enable the feature. Working with the new metadata in the middle and back end will come later. There are still a few rough edges but I'm putting these patches up now hoping to get feedback on the design and implementation from the upstream community.


Add the DIAssignID metadata attachment boilerplate. Includes a textual-bitcode roundtrip test.

This piece of metadata links together stores (used as an attachment) and the yet-to-be-added llvm.dbg.assign debug intrinsic (used as an operand).

Diff Detail

Event Timeline

Orlando created this revision.Aug 19 2022, 6:14 AM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: hiraditya. · View Herald Transcript
Orlando requested review of this revision.Aug 19 2022, 6:14 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 19 2022, 6:14 AM
Orlando updated this revision to Diff 456659.Aug 30 2022, 7:12 AM

+ Add context to diff

jmorse added a subscriber: jmorse.Aug 30 2022, 7:40 AM

This LGTM, you might want to add explicit tests that the verifier will catch erroneous textual IR, to make sure those code paths get exercised.

llvm/include/llvm/Bitcode/LLVMBitCodes.h
353

I wonder what the rules are about assigning these numbers -- they can create future backwards compatibility problems. I suppose this isn't a significant issue until LLVM starts generating bitcode containing these metadata nodes, something that isn't going to happen for quite a while (with this patch series being behind an experimental flag).

llvm/include/llvm/IR/DebugInfoMetadata.h
299
Orlando added inline comments.Sep 6 2022, 6:08 AM
llvm/lib/AsmParser/LLParser.cpp
4687–4688

@jmorse I was writing up the verifier tests you asked for and noticed that the verifier check that DIAssignID nodes are distinct doesn't fire because LLParser (here) gets there first. Do you have a a preference as to whether the check stays here or is removed (relying on the verifier to catch the error if it came from IR in a file)?

On the one hand, it's not a syntactic requirement for DIAssignID to be distinct. OTOH, it's a semantic requirement and we can catch it here.

Either way, we should keep the verifier check given a pass may possibly somehow generate non-distinct DIAssignID.

Orlando added inline comments.Sep 7 2022, 1:56 AM
llvm/lib/AsmParser/LLParser.cpp
4687–4688

It's also not possible to cause verifier failures by adding operands to DIAssignID (see code below), so I've just added a test the parser parses things expectedly in a new directory parse-and-verify.

Orlando updated this revision to Diff 458385.Sep 7 2022, 2:03 AM
Orlando marked an inline comment as done.

+ Add verifier & parsing failure tests: instruction-type.ll, operands.ll, distinct.ll
+ Strip DIAssignID in stripDebugInfo (DebugInfo.cpp) - caught by the test instruction-type.ll

Orlando updated this revision to Diff 458387.Sep 7 2022, 2:11 AM

+ Make test instruction-type.ll more robust
(Sorry for the noise)

jmorse added inline comments.Sep 8 2022, 4:23 AM
llvm/lib/AsmParser/LLParser.cpp
4687–4688

Blurgh. I think ultimately we'll just create more problems for ourselves if we make it so that you can't express IR that can be represented in memory -- AFAIUI that's why you can parse broken IR, and then it's the Verifier that complains about things like "use before def".

There's probably more value in ensuring the Verifier path is covered by a test, to ensure we catch the (rare but possible) scenarios of non-distinct DIAssignIDs. We don't gain anything by doing it the other way.

Orlando added inline comments.Sep 8 2022, 7:05 AM
llvm/lib/AsmParser/LLParser.cpp
4687–4688

Deleting the is-distinct check from the parser sounds reasonable to me. Hmm, actually, in D132222 I only added DIAssignID::getDistinct and not DIAssignID::get. So I'm not actually sure that it _is_ possible to create a non-distinct DIAssignID.

Judging by other metadata parsing functions I think it should be okay to leave the zero-operands check in the parser. Are you happy with that? In addition, similarly to the distinct issue above, I don't think there's actually an API available to create a DIAssignID with operands. Maybe it's possible if someone tried really hard, but I'm not sure how.

jmorse accepted this revision.Sep 13 2022, 9:42 AM

LGTM, if you're OK with the current configuration of where verifier checks / tests covering them happens.

llvm/lib/AsmParser/LLParser.cpp
4687–4688

Sooo, just because we can't create a non-distinct one now, doesn't mean someone won't invent a way of doing it in the future that we don't notice -- the benefit of having tests is that they're anchored to behaviour, rather than a particular implementation. (And in this case, we test that the verifier path actually works).

Leaving the operand check in the parser seems fine to me, there's much less opportunity for things to be subtly broken if DIAssignIDs accidentally carried operands.

This revision is now accepted and ready to land.Sep 13 2022, 9:42 AM
This revision was landed with ongoing or failed builds.Nov 3 2022, 4:24 AM
This revision was automatically updated to reflect the committed changes.
This revision is now accepted and ready to land.Nov 3 2022, 6:54 AM