[DebugInfo,test] Convert text files from CRLF to LF

[DebugInfo][RemoveDIs] Interpret DPValue objects in SelectionDAG (#72253)

DPValues are the non-intrinsic replacements for dbg.values, and when an
IR function is converted by SelectionDAG we need to

[DebugInfo][RemoveDIs] Interpret DPValue objects in SelectionDAG (#72253)

DPValues are the non-intrinsic replacements for dbg.values, and when an
IR function is converted by SelectionDAG we need to convert the variable
location information in the same way. Happily all the information is in
the same format, it's just stored in a slightly different object,
therefore this patch refactors a few things to store the set of
{Variable,Expr,DILocation,Location} instead of just a pointer to a
DbgValueInst.

This also adds a hook in llc that's much like the one I've added to opt
in PR #71937, allowing tests to optionally ask for the use RemoveDIs
mode if support for it is built into the compiler.

I've added that flag to a variety of SelectionDAG debug-info tests to
ensure that we get some coverage on the RemoveDIs / debug-info-iterator
buildbot.

show more ...

[DebugInfo] Allow non-stack_value variadic expressions and use in DBG_INSTR_REF

Prior to this patch, variadic DIExpressions (i.e. ones that contain
DW_OP_LLVM_arg) could only be created by salvaging

[DebugInfo] Allow non-stack_value variadic expressions and use in DBG_INSTR_REF

Prior to this patch, variadic DIExpressions (i.e. ones that contain
DW_OP_LLVM_arg) could only be created by salvaging debug values to create
stack value expressions, resulting in a DBG_VALUE_LIST being created. As of
the previous patch in this patch stack, DBG_INSTR_REF's syntax has been
changed to match DBG_VALUE_LIST in preparation for supporting variadic
expressions. This patch adds some minor changes needed to allow variadic
expressions that aren't stack values to exist, and allows variadic expressions
that are trivially reduceable to non-variadic expressions to be handled
similarly to non-variadic expressions.

Reviewed by: jmorse

Differential Revision: https://reviews.llvm.org/D133926

show more ...

[DebugInfo][NFC] Add new MachineOperand type and change DBG_INSTR_REF syntax

This patch makes two notable changes to the MIR debug info representation,
which result in different MIR output but ident

[DebugInfo][NFC] Add new MachineOperand type and change DBG_INSTR_REF syntax

This patch makes two notable changes to the MIR debug info representation,
which result in different MIR output but identical final DWARF output (NFC
w.r.t. the full compilation). The two changes are:

* The introduction of a new MachineOperand type, MO_DbgInstrRef, which
consists of two unsigned numbers that are used to index an instruction
and an output operand within that instruction, having a meaning
identical to first two operands of the current DBG_INSTR_REF
instruction. This operand is only used in DBG_INSTR_REF (see below).
* A change in syntax for the DBG_INSTR_REF instruction, shuffling the
operands to make it resemble DBG_VALUE_LIST instead of DBG_VALUE,
and replacing the first two operands with a single MO_DbgInstrRef-type
operand.

This patch is the first of a set that will allow DBG_INSTR_REF
instructions to refer to multiple machine locations in the same manner
as DBG_VALUE_LIST.

Reviewed By: jmorse

Differential Revision: https://reviews.llvm.org/D129372

show more ...

[test][DebugInfo] Convert some test cases to opaque pointers. NFC

Conversion performed using the script at:
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34

[DebugInfo][InstrRef][NFC] Test changes: DBG_VALUE to DBG_INSTR_REF

This patch contains a bunch of replacements of:

DBG_VALUE $somereg

with,

SOMEINST debug-instr-number1
DBG_INSTR_REF

[DebugInfo][InstrRef][NFC] Test changes: DBG_VALUE to DBG_INSTR_REF

This patch contains a bunch of replacements of:

DBG_VALUE $somereg

with,

SOMEINST debug-instr-number1
DBG_INSTR_REF 1, 0, ...

It's mostly SelectionDAG tests that are making sure that the variable
location assignment is placed in the correct position in the instructions.

To avoid a loss in test coverage of SelectionDAG, which is used by a lot
of different backends, all these tests now have two modes and sets of RUN
lines, one for DBG_VALUE mode, the other for instruction referencing.

Differential Revision: https://reviews.llvm.org/D114258

show more ...

[DebugInfo][NFC] Force some tests to not use instruction-referencing

There are various tests that need to be adjusted to test the right
thing with instruction referencing -- usually because the inte

[DebugInfo][NFC] Force some tests to not use instruction-referencing

There are various tests that need to be adjusted to test the right
thing with instruction referencing -- usually because the internal
representation of variables is different, sometimes that location lists
change. This patch makes a bunch of tests explicitly not use
instruction referencing, so that a check-llvm test with instruction
referencing on for x86_64 doesn't fail. I'll then convert the tests
to have instr-ref CHECK lines, and similar.

Differential Revision: https://reviews.llvm.org/D113194

show more ...

Rename ExpandISelPseudo->FinalizeISel, delay register reservation

This allows targets to make more decisions about reserved registers
after isel. For example, now it should be certain there are call

Rename ExpandISelPseudo->FinalizeISel, delay register reservation

This allows targets to make more decisions about reserved registers
after isel. For example, now it should be certain there are calls or
stack objects in the frame or not, which could have been introduced by
legalization.

Patch by Matthias Braun

llvm-svn: 363757

show more ...

MachineOperand/MIParser: Do not print debug-use flag, infer it

The debug-use flag must be set exactly for uses on DBG_VALUEs. This is
so obvious that it can be trivially inferred while parsing. Thi

MachineOperand/MIParser: Do not print debug-use flag, infer it

The debug-use flag must be set exactly for uses on DBG_VALUEs. This is
so obvious that it can be trivially inferred while parsing. This will
reduce noise when printing while omitting an information that has little
value to the user.

The parser will keep recognizing the flag for compatibility with old
`.mir` files.

Differential Revision: https://reviews.llvm.org/D53903

llvm-svn: 345671

show more ...

[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.

In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
nam

[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.

In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is

!DILabel(scope: !1, name: "foo", file: !2, line: 3)

We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is

llvm.dbg.label(metadata !1)

It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.

We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.

Differential Revision: https://reviews.llvm.org/D45024

Patch by Hsiangkai Wang.

llvm-svn: 331841

show more ...

Reapply "[SelectionDAG] Selection of DBG_VALUE using a PHI node result (pt 2)"

Summary:
This reverts SVN r331441 (reapplies r331337), together with a fix
in to handle an already existing fragment ex

Reapply "[SelectionDAG] Selection of DBG_VALUE using a PHI node result (pt 2)"

Summary:
This reverts SVN r331441 (reapplies r331337), together with a fix
in to handle an already existing fragment expression in the
dbg.value that must be fragmented due to a split PHI node.

This should solve the problem seen in PR37321, which was the
reason for the revert of r331337.

The situation in PR37321 is that we have a PHI node like this

%u.sroa = phi i80 [ %u.sroa.x, %if.x ],
[ %u.sroa.y, %if.y ],
[ %u.sroa.z, %if.z ]

and a dbg.value like this

call void @llvm.dbg.value(metadata i80 %u.sroa,
metadata !13,
metadata !DIExpression(DW_OP_LLVM_fragment, 0, 80))

The phi node is split into three 32-bit PHI nodes

%30:gr32 = PHI %11:gr32, %bb.4, %14:gr32, %bb.5, %27:gr32, %bb.8
%31:gr32 = PHI %12:gr32, %bb.4, %15:gr32, %bb.5, %28:gr32, %bb.8
%32:gr32 = PHI %13:gr32, %bb.4, %16:gr32, %bb.5, %29:gr32, %bb.8

but since the original value only is 80 bits we need to adjust the size
of the last fragment expression, and with this patch we get

DBG_VALUE debug-use %30:gr32, debug-use $noreg, !"u", !DIExpression(DW_OP_LLVM_fragment, 0, 32)
DBG_VALUE debug-use %31:gr32, debug-use $noreg, !"u", !DIExpression(DW_OP_LLVM_fragment, 32, 32)
DBG_VALUE debug-use %32:gr32, debug-use $noreg, !"u", !DIExpression(DW_OP_LLVM_fragment, 64, 16)

Reviewers: vsk, aprantl, mstorsjo

Reviewed By: aprantl

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D46384

llvm-svn: 331464

show more ...

[SelectionDAG] Selection of DBG_VALUE using a PHI node result (pt 2)

Summary:
This is a follow up to rL331182. A PHI node can be split up into
several MIR PHI nodes when being selected. When there i

[SelectionDAG] Selection of DBG_VALUE using a PHI node result (pt 2)

Summary:
This is a follow up to rL331182. A PHI node can be split up into
several MIR PHI nodes when being selected. When there is a
dbg.value intrinsic that uses the result of such a PHI node we
need to select several DBG_VALUE instructions, with fragment
expressions, in order to do a correct selection.

Reviewers: rnk, aprantl, vsk

Reviewed By: vsk

Subscribers: mattd, llvm-commits, JDevlieghere, aprantl, gbedwell, rnk

Tags: #debug-info

Differential Revision: https://reviews.llvm.org/D46329

llvm-svn: 331337

show more ...