This is an archive of the discontinued LLVM Phabricator instance.

[mem2reg][debuginfo] Handle op_deref when converting dbg.declare
ClosedPublic

Authored by fdeazeve on Jan 19 2023, 2:29 PM.

Details

Summary

The conversion of dbg.declare into dbg.values doesn't take into account
the DIExpression attached to the intrinsic. In particular, when
converting:

store %val, ptr %alloca
dbg.declare(ptr %alloca, !SomeVar, !DIExpression())

Mem2Reg will try to figure out if %val has the size of !SomeVar. If
it does, then a non-undef dbg.value is inserted:

dbg.value(%val, !SomeVar, !DIExpression())

This makes sense: the alloca is _the_ address of the variable. So a
store to the alloca is a store to the variable. However, if the
expression in the original intrinsic is a DW_OP_deref, this logic is
not applicable:

store ptr %val, ptr %alloca
dbg.declare(ptr %alloca, !SomeVar, !DIExpression(DW_OP_deref))

Here, the alloca is *not* the address of the variable. A store to the
alloca is *not* a store to the variable. As such, querying whether
%val has the same size as !SomeVar is meaningless.

This patch addresses the issue by:

  1. Allowing the conversion when the expression is _only_ a DW_OP_deref

without any other expressions (see code comment).

  1. Checking that the expression does not start with a DW_OP_deref

before applying the logic that checks whether the value being stored and
the variable have the same length.

Diff Detail

Event Timeline

fdeazeve created this revision.Jan 19 2023, 2:29 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 19 2023, 2:29 PM
fdeazeve requested review of this revision.Jan 19 2023, 2:29 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 19 2023, 2:29 PM
aprantl added inline comments.
llvm/lib/Transforms/Utils/Local.cpp
1534

I'm not sure the second half of this sentence is necessarily true, I think it's more an emergent behavior of the instruction selector, because at the LLVM IR level we don't really distinguish what DWARF calls location description kinds, but it certainly correct that the two are not equivalent.

One thing you could do is define the semantics of dbg.declare(alloca, var, DIExpression(DW_OP_deref)) as the alloca holding the canonical address of var, *which may not change throughout the entire function*. Patching LangRef this way would allow you to do the kind of transformation that you need here.

I'm also curious if how we defined llvm.dbg.addr() and if it would be of any use here.

Orlando added inline comments.
llvm/lib/Transforms/Utils/Local.cpp
1534

+ to everything @aprantl said. Note that dbg.addr may be on the way out - see this discourse post.

I could be wrong but I don't think the dbg.value in the example looks quite right - IIRC it should end with either a stack_value or deref operand if the expression is non-empty because dbg.values are essentially implicit location descriptions (describing the value of the variable rather than its location).

fdeazeve updated this revision to Diff 492232.Jan 25 2023, 12:43 PM

Updated comment to address review comments, rebased.

llvm/lib/Transforms/Utils/Local.cpp
1534

I could be wrong but I don't think the dbg.value in the example looks quite right

It is indeed intentionally wrong, the comment was attempting to explain why doing the conversion of dbg.declare -> dbg.value would be incorrect in that case. I've updated the comment.

I'm also curious if how we defined llvm.dbg.addr() and if it would be of any use here.

As per the link Orlando posted, the intrinsic is indeed going away, and the recommendation is to replace dbg.addr with a dbg.value + op_deref (which is what is being generated here!).

This should now be ready for review

aprantl accepted this revision.Jan 27 2023, 11:14 AM
This revision is now accepted and ready to land.Jan 27 2023, 11:14 AM

Sorry for the slow turn around on this review - LGTM too, thanks!

llvm/include/llvm/IR/DebugInfoMetadata.h
2772

nit: exactly one operator / expression operator / operation etc?

fdeazeve added a comment.EditedJan 30 2023, 6:25 AM

nit: exactly one operator / expression operator / operation etc?

Great point! Will fix

fdeazeve updated this revision to Diff 493299.Jan 30 2023, 6:27 AM

Rebased and updated comment in header file.