summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
diff options
context:
space:
mode:
authorReid Kleckner <rnk@google.com>2017-10-03 17:59:02 +0000
committerReid Kleckner <rnk@google.com>2017-10-03 17:59:02 +0000
commit04e25e00b7fa8e8bc680acc548ca3734cc66d1ab (patch)
treed0900d714474020faf23dbb964b55d13830b4a8b /llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
parent1821a7b3cbc4f577734539ad834a35989c9d9dad (diff)
downloadbcm5719-llvm-04e25e00b7fa8e8bc680acc548ca3734cc66d1ab.tar.gz
bcm5719-llvm-04e25e00b7fa8e8bc680acc548ca3734cc66d1ab.zip
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values
Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
Diffstat (limited to 'llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud