For Clang, `MCUseDwarfDirectory` is true by default for the majority cases
(-fintegrated-as or -gdwarf-5; most targets use -fintegrated-as by default).
Defaulting MCUseDwarfDirectory to true can reduce the differences between clang
and llc.
Reviewed By: #debug-info, dblaikie
Differential Revision: https://reviews.llvm.org/D105856
Summary: When -strict-dwarf=true is specified, the calling convention info
DW_CC_pass_by_value or DW_CC_pass_by_reference can only be generated at DWARF5.
Reviewed By: shchenz, dblaikie
Differential Revision: https://reviews.llvm.org/D103300
This patch is a fix for revision ce0c1f3c, which caused test failures on
bots without x86 as a registered target. This patch moves the test added
in the prior patch to the x86 folder, so that it only runs on bots with
the correct target available.
This patch fixes a crash in the compiler that occurs when certain
invalidated SDDbgValues are emitted. The cause of this was that we would
attempt to check the liveness of the debug value's operands, which
triggers an assert if any of those operands are invalid. This patch
changes this check such that it only occurs if the SDDbgValue is valid;
if not, the check is irrelevant anyway, so can be safely ignored.
Differential Revision: https://reviews.llvm.org/D101540
This patch fixes an issue in which ConstantAsMetadata arguments to a
DIArglist, as well as the Constant values referenced by that metadata,
would not be always be emitted correctly into bitcode. This patch fixes
this issue firstly by searching for ConstantAsMetadata in DIArgLists
(previously we would only search for them when directly wrapped in
MetadataAsValue), and secondly by enumerating all of a DIArgList's
arguments directly prior to enumerating the DIArgList itself.
This patch also adds a number of asserts, and no longer treats the
arguments to a DIArgList as optional fields when reading/writing to
bitcode.
Differential Revision: https://reviews.llvm.org/D100572
Value::replaceUsesOutsideBlock doesn't replace debug uses which leads to an
unnecessary reduction in variable location coverage. Fix this, add a unittest for
it, and add a regression test demonstrating the change through instcombine's
replacedSelectWithOperand.
Reviewed By: djtodoro
Differential Revision: https://reviews.llvm.org/D99169
D73568 removed the lit feature object-emission, because it was introduced for a
target which did not support the integrated assembler, and that target no longer
required the feature. XCore still does not support the integrated assembler,
so a build with XCore as the default target fails tests requiring
object-emission. This issue was not publicly visible because there was not a
buildbot for XCore as the default target. We fixed the failures downstream. We
now have builder clang-xcore-ubuntu-20-x64 on the staging buildmaster, which
shows the failures. We would like to make upstream build green.
Omit DebugInfo/Generic on XCore to avoid annotating 70 separate files.
Differential Revision: https://reviews.llvm.org/D98508
Value::replaceUsesOutsideBlock doesn't replace debug uses which leads to an
unnecessary reduction in variable location coverage. Fix this, add a unittest for
it, and add a regression test demonstrating the change through instcombine's
replacedSelectWithOperand.
Reviewed By: djtodoro
Differential Revision: https://reviews.llvm.org/D99169
This commit adds debugging support for set types defined in languages
such as Pascal and Modula-2.
Patch by Peter McKinna!
Differential Revision: https://reviews.llvm.org/D76115
XCore default subtarget does not support 8-byte stack alignment. These failures
can be seen on builder clang-xcore-ubuntu-20-x64 on staging buildbot.
Differential Revision: https://reviews.llvm.org/D99092
This patch adds a new metadata node, DIArgList, which contains a list of SSA
values. This node is in many ways similar in function to the existing
ValueAsMetadata node, with the difference being that it tracks a list instead of
a single value. Internally, it uses ValueAsMetadata to track the individual
values, but there is also a reasonable amount of DIArgList-specific
value-tracking logic on top of that. Similar to ValueAsMetadata, it is a special
case in parsing and printing due to the fact that it requires a function state
(as it may reference function-local values).
This patch should not result in any immediate functional change; it allows for
DIArgLists to be parsed and printed, but debug variable intrinsics do not yet
recognize them as a valid argument (outside of parsing).
Differential Revision: https://reviews.llvm.org/D88175
See original comment in 560ce2c70f
Baiscally the default seed value results in less collision, but changes the
iteration order, which matters for a few test cases.
Differential Revision: https://reviews.llvm.org/D97396
Originally landed in ddc2f1e3fb and reverted in d32deaab4d because of
a Generic test objecting. That was fixed up in 013613964f. Original
landing commit message follows:
[DWARF] Location-less inlined variables should not have DW_TAG_variable
Discussed in this thread:
https://lists.llvm.org/pipermail/llvm-dev/2021-January/148139.html
DwarfDebug::collectEntityInfo accidentally distinguishes between variable
locations that never have a location specified, and variable locations that
have an empty location specified. The latter leads to the creation of an
empty variable referring to the abstract origin.
Fix this by seeking a non-empty location before producing a concrete
entity, to guarantee a DW_AT_location will be produced. Other loops in
collectEntityInfo and endFunctionImpl take care of examining the
retainedNodes collection and ensuring optimised-out variables are created.
Differential Revision: https://reviews.llvm.org/D95617
Was e05c10380c, reverted in d7d0b17de7, see D95617 for details. I've
added "arm64" to the XFail list (as well as aarch64), will follow up on
the mailing list about whether there's anything else to be done.
This reverts commit 4fd29e4fd3.
There's a report in D95617 that this is failing on what (I think?) is an
aarch64 bot, which should be covered by the XFail list... reverting this
follow-up and the base patch until I work out what's wrong here.
In the LLVM-IR for this test, the inlined argument "b" in the "a" function
is optimized out on certain architectures, not on others. This hasn't been
reported as a test failure since 93faeecd8f and ff2073a51 because we would
create a variable that looks like this:
DW_TAG_formal_parameter
DW_AT_abstract_origin
With no further information (and no location). With D95617 however, we
stop emitting such variables.
Prior to landing D95617: make this test stricter by checking that the
variable mentioned above has a location. We have to accept that on certain
architectures this goes missing, so add those to the XFail list.
I've run a few experiments, and right now it looks likely only powerpc64
still drops the variable location.
Discussed in this thread:
https://lists.llvm.org/pipermail/llvm-dev/2021-January/148139.html
DwarfDebug::collectEntityInfo accidentally distinguishes between variable
locations that never have a location specified, and variable locations that
have an empty location specified. The latter leads to the creation of an
empty variable referring to the abstract origin.
Fix this by seeking a non-empty location before producing a concrete
entity, to guarantee a DW_AT_location will be produced. Other loops in
collectEntityInfo and endFunctionImpl take care of examining the
retainedNodes collection and ensuring optimised-out variables are created.
Differential Revision: https://reviews.llvm.org/D95617
Minimum amount of tests to cover (most) of the DISubprogram verifier
checks.
Reviewed By: vsk
Differential Revision: https://reviews.llvm.org/D90340
Change-Id: Icd25dac64f87f6dcf67ff3443eb4f95af18d05a8
This patch copies @vsk's fix to instcombine from D85555 over to mem2reg. The
motivation and rationale are exactly the same: When mem2reg removes an alloca,
it erases the dbg.{addr,declare} instructions which refer to the alloca. It
would be better to instead remove all debug intrinsics which describe the
contents of the dead alloca, namely all dbg.value(<dead alloca>, ...,
DW_OP_deref)'s.
As far as I can tell, prior to D80264 these `dbg.value+deref`s would have been
silently dropped instead of being made `undef`, so we're just returning to
previous behaviour with these patches.
Testing:
`llvm-lit llvm/test` and `ninja check-clang` gave no unexpected failures. Added
3 tests, each of which covers a dbg.value deletion path in mem2reg:
mem2reg-promote-alloca-1.ll
mem2reg-promote-alloca-2.ll
mem2reg-promote-alloca-3.ll
The first is based on the dexter test inlining.c from D89543. This patch also
improves the debugging experience for loop.c from D89543, which suffers
similarly after arg promotion instead of inlining.
attachments. They would crash the backend, which expects all
DISubprograms that are not part of the type system to have a unit field.
Clang right before https://reviews.llvm.org/D79967 would generate this
kind of broken IR.
rdar://problem/69534688
Thanks to Fangrui for fixing an assembler test I had missed!
https://reviews.llvm.org/D88270
attachments. They would crash the backend, which expects all
DISubprograms that are not part of the type system to have a unit field.
Clang right before https://reviews.llvm.org/D79967 would generate this
kind of broken IR.
rdar://problem/69534688
Introduce a helper which can be used to update the debug location of an
Instruction after the instruction is hoisted. This can be used to safely
drop a source location as recommended by the docs.
For more context, see the discussion in https://reviews.llvm.org/D60913.
Differential Revision: https://reviews.llvm.org/D85670
As discussed in D86843, -earlycse-debug-hash should be used in more regression
tests to catch inconsistency between the hashing and the equivalence check.
Differential Revision: https://reviews.llvm.org/D86863
This reads more like what you'd expect the DWARF to look like (from the
lexical order of C++ - template parameters come before members, etc),
and also happens to make it easier to tickle (& thus test) a bug related
to type units and Split DWARF I'm about to fix.
Currently only two test failures remain on Sparc, both
`sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`:
LLVM :: DebugInfo/Generic/debug-label-inline.ll
LLVM :: Linker/subprogram-linkonce-weak.ll
They seem related in that debug info isn't generated for instruction
bundles (like `retl+add` in the delay slot).
I've filed separate bugs for both files (Bug 47129 and 47131), though it's
probably the same issue.
This patch `XFAIL`s the tests.
Tested on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D85827
When turning on -debug-info-kind=constructor we ran into a "fragment covers
entire variable" error during thinlto. The fragment is currently always
emitted if there is no type size, but sometimes the variable has a
forward declared struct type which doesn't have a size.
This changes the code to get the type size from the GlobalVariable instead.
Differential Revision: https://reviews.llvm.org/D85572
Introduce a helper on Instruction which can be used to update the debug
location after hoisting.
Use this in GVN and LICM, where we were mistakenly introducing new line
0 locations after hoisting (the docs recommend dropping the location in
this case).
For more context, see the discussion in https://reviews.llvm.org/D60913.
Differential Revision: https://reviews.llvm.org/D85670
Two DebugInfo tests currently `FAIL` on Sparc:
LLVM :: DebugInfo/Generic/2010-06-29-InlinedFnLocalVar.ll
LLVM :: DebugInfo/Generic/array.ll
both in a similar way. E.g.
: 'RUN: at line 1'; /var/llvm/local-sparcv9-A/bin/llc -O2 /vol/llvm/src/llvm-project/local/llvm/test/DebugInfo/Generic/2010-06-29-InlinedFnLocalVar.ll -o - | /var/llvm/local-sparcv9-A/bin/FileCheck /vol/llvm/src/llvm-project/local/llvm/test/DebugInfo/Generic/2010-06-29-InlinedFnLocalVar.ll
/vol/llvm/src/llvm-project/local/llvm/test/DebugInfo/Generic/2010-06-29-InlinedFnLocalVar.ll:4:10: error: CHECK: expected string not found in input
; CHECK: debug_info,
^
On `amd64-pc-solaris2.11`, the corresponding line is
.section .debug_info,"",@progbits
while on `sparcv9-sun-solaris2.11` we have only
.section .debug_info
This happens because Sparc currently emits `.section` directives using the
style of the Solaris/SPARC assembler (controlled by `SunStyleELFSectionSwitchSyntax`).
This patch takes the easy way out and allows both forms while tightening the
check to only match the `.section` directive.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`,
`x86_64-pc-linux-gnu`, and `x86_64-apple-darwin20.0.0`.
Differential Revision: https://reviews.llvm.org/D85414
For most tables, we already use commas in headers. This set of patches
unifies dumping the remaining ones.
Differential Revision: https://reviews.llvm.org/D80806
Summary: The lit feature object-emission was added because Hexagon did not support the integrated assembler, so some tests needed to be turned off with a Hexagon target. Hexagon now supports the integrated assembler, so this feature can be removed.
Reviewers: bcain, kparzysz, jverma, whitequark, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: mehdi_amini, hiraditya, steven_wu, dexonsmith, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73568
The code paths in the absence of TargetMachine, TargetLowering or
TargetRegisterInfo are poorly tested. As rL285987 said, requiring
TargetPassConfig allows us to delete many (untested) checks littered
everywhere.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D73754
Fangrui Song