Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-01-29T21:18:16+00:00 2020-01-29T21:18:16+00:00 Vedant Kumar vsk@apple.com 2020-01-25T02:07:34+00:00 urn:sha1:b516ca061838e2cb8b48b31ee113e3c4aae7e7d5 ... as well as: Revert "[DWARF] Defer creating declaration DIEs until we prepare call site info" This reverts commit fa4701e1979553c2df61698ac1ac212627630442. This reverts commit 79daafc90308787b52a5d3a7586e82acd5e374b3. There have been reports of this assert getting hit: CalleeDIE && "Could not find DIE for call site entry origin (cherry picked from commit 802bec896171997a7b73dde3857712e0eedeabc1) 2020-01-14T15:51:11+00:00 Tom Weaver Tom.Weaver@Sony.com 2020-01-14T15:51:11+00:00 urn:sha1:e7b2d9f4702cb8882aa275bcb8eab37be17601e1 Adds 22 distinct tests that exercise the live-debug-values passes expected behaviour. reviewers: aprantl, vsk Differential revision: https://reviews.llvm.org/D72515 2020-01-14T15:12:02+00:00 Tom Weaver Tom.Weaver@Sony.com 2020-01-14T15:12:02+00:00 urn:sha1:b10f6b7112278ba91d57173466bff7fc85d4bf0d This reverts commit 35787e3a062a4a21c145137552d20cb1169c74fc. 2020-01-14T14:43:30+00:00 Tom Weaver Tom.Weaver@Sony.com 2020-01-14T14:43:30+00:00 urn:sha1:35787e3a062a4a21c145137552d20cb1169c74fc Adds 22 distinct tests that exercise the live-debug-values passes expected behaviour. reviewers: aprantl, vsk Differential revision: https://reviews.llvm.org/D72515 2019-12-25T00:27:51+00:00 Fangrui Song maskray@google.com 2019-12-25T00:11:33+00:00 urn:sha1:a36ddf0aa9db5c1086e04f56b5f077b761712eb5 2019-12-25T00:05:15+00:00 Fangrui Song maskray@google.com 2019-12-25T00:02:47+00:00 urn:sha1:eb16435b5e5df68d2410bbe4c08ef8ce8aa8b2f4 2019-12-20T23:26:31+00:00 Vedant Kumar vsk@apple.com 2019-12-20T23:12:18+00:00 urn:sha1:fa4701e1979553c2df61698ac1ac212627630442 It isn't necessary to create DIEs for all of the declaration subprograms in a CU's retainedTypes list. We can defer creating these subprograms until we need to prepare a call site tag that refers to one. This cleanup was mentioned in passing in D70350. 2019-12-13T09:49:46+00:00 David Stenberg david.stenberg@ericsson.com 2019-12-13T09:37:53+00:00 urn:sha1:5c7cc6f83d1f3ea2016d94e1c9cc25f814d2671b Summary: This is a quickfix for PR44275. An assertion that checks that the DIExpression is valid failed due to attempting to create an entry value for an indirect parameter. This started appearing after D69028, as the indirect parameter started being represented using an DW_OP_deref, rather than with the DBG_VALUE's second operand, meaning that the isIndirectDebugValue() check in LiveDebugValues did not exclude such parameters. A DIExpression that has an entry value operation can currently not have any other operation, leading to the failed isValid() check. This patch simply makes us stop considering emitting entry values for such parameters. To support such cases I think we at least need to do the following changes: * In DIExpression::isValid(): Remove the limitation that a DW_OP_LLVM_entry_value operation can be the only operation in a DIExpression. * In LiveDebugValues::emitEntryValues(): Create an entry value of size 1, so that it only wraps the register operand, and not the whole pre-existing expression (the DW_OP_deref). * In LiveDebugValues::removeEntryValue(): Check that the new debug value has the same debug expression as the original, rather than checking that the debug expression is empty. * In DwarfExpression::addMachineRegExpression(): Modify the logic so that a DW_OP_reg* expression is emitted for the entry value. That is how GCC emits entry values for indirect parameters. That will currently not happen to due the DW_OP_deref causing the !HasComplexExpression to fail. The LocationKind needs to be changed also, rather than always emitting a DW_OP_stack_value for entry values. There are probably more things I have missed, but that could hopefully be a good starting point for emitting such entry values. Reviewers: djtodoro, aprantl, jmorse, vsk Reviewed By: aprantl, vsk Subscribers: hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D71416 2019-12-10T18:20:11+00:00 Hans Wennborg hans@chromium.org 2019-12-10T18:09:24+00:00 urn:sha1:49da20ddb4319f3f469499e341a1bc3101adcdcf This caused non-determinism in the compiler, see command on the Phabricator code review. > This patch addresses a performance problem reported in PR43855, and > present in the reapplication in in 001574938e5. It turns out that > MachineSink will (often) move instructions to the first block that > post-dominates the current block, and then try to sink further. This > means if we have a lot of conditionals, we can needlessly create large > numbers of DBG_VALUEs, one in each block the sunk instruction passes > through. > > To fix this, rather than immediately sinking DBG_VALUEs, record them in > a pass structure. When sinking is complete and instructions won't be > sunk any further, new DBG_VALUEs are added, avoiding lots of > intermediate DBG_VALUE $noregs being created. > > Differential revision: https://reviews.llvm.org/D70676 2019-12-09T09:47:49+00:00 David Stenberg david.stenberg@ericsson.com 2019-12-09T09:46:16+00:00 urn:sha1:6965f835b476f8e8eb55916cac39be7ffe639866 Summary: Currently the describeLoadedValue() hook is assumed to describe the value of the instruction's first explicit define. The hook will not be called for instructions with more than one explicit define. This commit adds a register parameter to the describeLoadedValue() hook, and invokes the hook for all registers in the worklist. This will allow us to for example describe instructions which produce more than two parameters' values; e.g. Hexagon's various combine instructions. This also fixes situations in our downstream target where we may pass smaller parameters in the high part of a register. If such a parameter's value is produced by a larger copy instruction, we can't describe the call site value using the super-register, and we instead need to know which sub-register that should be used. This also allows us to handle cases like this: $ebx = [...] $rdi = MOVSX64rr32 $ebx $esi = MOV32rr $edi CALL64pcrel32 @call The hook will first be invoked for the MOV32rr instruction, which will say that @call's second parameter (passed in $esi) is described by $edi. As $edi is not preserved it will be added to the worklist. When we get to the MOVSX64rr32 instruction, we need to describe two values; the sign-extended value of $ebx -> $rdi for the first parameter, and $ebx -> $edi for the second parameter, which is now possible. This commit modifies the dbgcall-site-lea-interpretation.mir test case. In the test case, the values of some 32-bit parameters were produced with LEA64r. Perhaps we can in general cases handle such by emitting expressions that AND out the lower 32-bits, but I have not been able to land in a case where a LEA64r is used for a 32-bit parameter instead of LEA64_32 from C code. I have not found a case where it would be useful to describe parameters using implicit defines, so in this patch the hook is still only invoked for explicit defines of forwarding registers. Reviewers: djtodoro, NikolaPrica, aprantl, vsk Reviewed By: djtodoro, vsk Subscribers: ormris, hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D70431