This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo][MachineSink] Don't stop copy-propagating DBG_VALUEs that will have a sunk copy created
Needs ReviewPublic

Authored by jmorse on Dec 10 2019, 8:47 AM.

Details

Summary

When sinking instructions, and sinking DBG_VALUEs at the same time, we leave one DBG_VALUE at the source location to either mark an undef location, or copy-propagate it if it can be recovered. However, this remaining DBG_VALUE wasn't receiving any further copy propagation (there can be multiple copies in a row), potentially leading to a debug use-before-def. Fix this by trying to copy-propagate all DBG_VALUEs, including those that used to refer to a sunk instruction,

While we're at it, "PerformTrivialForwardCoalescing" occasionally eliminates COPYs, leading to dropped variable locations in one of the added tests. Fix this by updating our list of debug-users-of-vregs whenever we coalesce a register this way.

There are zero changes to the location statistics for a clang-3.4 build with this patch (alas), it's purely a correctness thing.

You may notice that MachineSink.cpp seems to be accumulating a lot of debug related stuff... this is partially because it's had my attention through its use of collectDebugValues, but I would also describe shuffling DBG_VALUEs around as "fiddly". I'll see at some point whether this can be generalised in some way.

Diff Detail

Event Timeline

jmorse created this revision.Dec 10 2019, 8:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 10 2019, 8:47 AM
aprantl added inline comments.Dec 10 2019, 9:15 AM
llvm/lib/CodeGen/MachineSink.cpp
1084

if (!AlreadySinking) ?

1091

generally, the control flow here isn't quite obvious. It almost looks like a mistake that the instructions inserted into the set on the line above aren't counted here, but I think it's intentional. Is there a way to make it more obvious? Perhaps by renaming the AlreadySinking variable?

I think you're on the right track. My mir-reproducer passes with this patch, so now I get the wanted

%6:an32_rn_pairs = COPY %5.hiAcc
%8:an32_0_7 = COPY %6
DBG_VALUE %8, [...]

instead of the previous

%6:an32_rn_pairs = COPY %5.hiAcc
%8:an32_0_7 = COPY %6
DBG_VALUE %8.hiAcc:an32_0_7, [...]