DbgValueHistoryCalculator: Store modified registers in a BitVector instead of std::set. And iterate over the smaller map instead of the larger set first. Reduces the time spent in calculateDbgValueHistory by 30-40%. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219123 91177308-0d34-0410-b5e6-96231b3b80d8
Move the complex address expression out of DIVariable and into an extra argument of the llvm.dbg.declare/llvm.dbg.value intrinsics. Previously, DIVariable was a variable-length field that has an optional reference to a Metadata array consisting of a variable number of complex address expressions. In the case of OpPiece expressions this is wasting a lot of storage in IR, because when an aggregate type is, e.g., SROA'd into all of its n individual members, the IR will contain n copies of the DIVariable, all alike, only differing in the complex address reference at the end. By making the complex address into an extra argument of the dbg.value/dbg.declare intrinsics, all of the pieces can reference the same variable and the complex address expressions can be uniqued across the CU, too. Down the road, this will allow us to move other flags, such as "indirection" out of the DIVariable, too. The new intrinsics look like this: declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr) declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr) This patch adds a new LLVM-local tag to DIExpressions, so we can detect and pretty-print DIExpression metadata nodes. What this patch doesn't do: This patch does not touch the "Indirect" field in DIVariable; but moving that into the expression would be a natural next step. http://reviews.llvm.org/D4919 rdar://problem/17994491 Thanks to dblaikie and dexonsmith for reviewing this patch! Note: I accidentally committed a bogus older version of this patch previously. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218787 91177308-0d34-0410-b5e6-96231b3b80d8
Revert r218778 while investigating buldbot breakage. "Move the complex address expression out of DIVariable and into an extra" git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218782 91177308-0d34-0410-b5e6-96231b3b80d8
Move the complex address expression out of DIVariable and into an extra argument of the llvm.dbg.declare/llvm.dbg.value intrinsics. Previously, DIVariable was a variable-length field that has an optional reference to a Metadata array consisting of a variable number of complex address expressions. In the case of OpPiece expressions this is wasting a lot of storage in IR, because when an aggregate type is, e.g., SROA'd into all of its n individual members, the IR will contain n copies of the DIVariable, all alike, only differing in the complex address reference at the end. By making the complex address into an extra argument of the dbg.value/dbg.declare intrinsics, all of the pieces can reference the same variable and the complex address expressions can be uniqued across the CU, too. Down the road, this will allow us to move other flags, such as "indirection" out of the DIVariable, too. The new intrinsics look like this: declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr) declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr) This patch adds a new LLVM-local tag to DIExpressions, so we can detect and pretty-print DIExpression metadata nodes. What this patch doesn't do: This patch does not touch the "Indirect" field in DIVariable; but moving that into the expression would be a natural next step. http://reviews.llvm.org/D4919 rdar://problem/17994491 Thanks to dblaikie and dexonsmith for reviewing this patch! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218778 91177308-0d34-0410-b5e6-96231b3b80d8
Improve performance of calculateDbgValueHistory. In r210492 the logic of calculateDbgValueHistory was changed to end register variable live ranges at the end of MBB conditionally on the fact that the register was or not clobbered by the function body. This requires an initial scan of all the operands of the function to collect all clobbered registers. In a second pass over all instructions, we compare this set with the set of clobbered registers for the current MachineInstruction. This modification incurred a compilation time regression on some benchmarks: the debug info emission phase takes ~10% more time. While a small performance hit is unavoidable due to the initial scan requirement, we can improve the situation by avoiding to create too many temporary sets and just use lambdas to work directly on the result of the initial scan. Fixes <rdar://problem/17884104> Patch by Frederic Riss! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214987 91177308-0d34-0410-b5e6-96231b3b80d8
Cleanup collectChangingRegs The handling of the epilogue is best expressed as an early exit and there is no reason to look for register defs in DbgValue MIs. Patch by Frederic Riss! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214986 91177308-0d34-0410-b5e6-96231b3b80d8
Debug info: Infrastructure to support debug locations for fragmented variables (for example, by-value struct arguments passed in registers, or large integer values split across several smaller registers). On the IR level, this adds a new type of complex address operation OpPiece to DIVariable that describes size and offset of a variable fragment. On the DWARF emitter level, all pieces describing the same variable are collected, sorted and emitted as DWARF expressions using the DW_OP_piece and DW_OP_bit_piece operators. http://reviews.llvm.org/D3373 rdar://problem/15928306 What this patch doesn't do / Future work: - This patch only adds the backend machinery to make this work, patches that change SROA and SelectionDAG's type legalizer to actually create such debug info will follow. (http://reviews.llvm.org/D2680) - Making the DIVariable complex expressions into an argument of dbg.value will reduce the memory footprint of the debug metadata. - The sorting/uniquing of pieces should be moved into DebugLocEntry, to facilitate the merging of multi-piece entries. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214576 91177308-0d34-0410-b5e6-96231b3b80d8
Generate better location ranges for some register-described variables. Don't terminate location ranges for register-described variables at the end of machine basic block if this register is never modified in the function body, except for the prologue and epilogue. Prologue location is guessed by FrameSetup flags on MachineInstructions, while epilogue location is deduced from debug locations of instructions in the basic blocks ending with return instructions. This patch is mostly targeted to fix non-trivial debug locations for variables addressed via stack and frame pointers. It is not really a generic fix. We can still produce poor debug info for register-described variables if this register *is* modified somewhere in the function, but in unrelated places. This might be the case for the debug info in optimized binaries (e.g. for local variables in inlined functions). LiveDebugVariables pass in CodeGen attempts to fix this problem by adjusting DBG_VALUE instructions, but this pass is tied to greedy register allocator, which is used in optimized builds only. Proper fix would likely involve generalizing LiveDebugVariables to all register allocators. See more discussion in http://reviews.llvm.org/D3933 review thread. I'm proceeding with this patch to fix immediate severe problems and important cases, e.g. fix completely broken debug info with AddressSanitizer and fix PR19307 (missing debug info for by-value std::string arguments). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210492 91177308-0d34-0410-b5e6-96231b3b80d8
Change representation of instruction ranges where variable is accessible. Use more straightforward way to represent the set of instruction ranges where the location of a user variable is defined - vector of pairs of instructions (defining start/end of each range), instead of a flattened vector of instructions where some instructions are supposed to start the range, and the rest are supposed to "clobber" it. Simplify the code which generates actual .debug_loc entries. No functionality change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209698 91177308-0d34-0410-b5e6-96231b3b80d8
Don't pre-populate the set of keys in the map with variable locations history. Current implementation of calculateDbgValueHistory already creates the keys in the expected order (user variables are listed in order of appearance), and should do so later by contract. No functionality change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209690 91177308-0d34-0410-b5e6-96231b3b80d8
Rewrite calculateDbgValueHistory to make it (hopefully) more transparent. This change preserves the original algorithm of generating history for user variables, but makes it more clear. High-level description of algorithm: Scan all the machine basic blocks and machine instructions in the order they are emitted to the object file. Do the following: 1) If we see a DBG_VALUE instruction, add it to the history of the corresponding user variable. Keep track of all user variables, whose locations are described by a register. 2) If we see a regular instruction, look at all the registers it clobbers, and terminate the location range for all variables described by these registers. 3) At the end of the basic block, terminate location ranges for all user variables described by some register. Although this change shouldn't be user-visible (the contents of .debug_loc section should be the same), it changes some internal assumptions about the set of instructions used to track the variable locations. Watching the bots. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209225 91177308-0d34-0410-b5e6-96231b3b80d8
Convert more loops to range-based equivalents git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207714 91177308-0d34-0410-b5e6-96231b3b80d8
Move logic for calculating DBG_VALUE history map into separate file/class. Summary: No functionality change. Test Plan: llvm regression test suite. Reviewers: dblaikie Reviewed By: dblaikie Subscribers: echristo, llvm-commits Differential Revision: http://reviews.llvm.org/D3573 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207708 91177308-0d34-0410-b5e6-96231b3b80d8