Fixup for rL326769 (RegState::Debug is being truncated to a bool)

I obviously messed up arguments to MachineOperand::CreateReg
in rL326769. This should make it work as intended.

Thanks to RKSimon f

Fixup for rL326769 (RegState::Debug is being truncated to a bool)

I obviously messed up arguments to MachineOperand::CreateReg
in rL326769. This should make it work as intended.

Thanks to RKSimon for spotting this.

llvm-svn: 326780

show more ...

[DebugInfo] Discard invalid DBG_VALUE instructions in LiveDebugVariables

Summary:
This is a workaround for pr36417
https://bugs.llvm.org/show_bug.cgi?id=36417

LiveDebugVariables will now verify tha

[DebugInfo] Discard invalid DBG_VALUE instructions in LiveDebugVariables

Summary:
This is a workaround for pr36417
https://bugs.llvm.org/show_bug.cgi?id=36417

LiveDebugVariables will now verify that the DBG_VALUE instructions
are sane (prior to register allocation) by asking LIS if a virtual
register used in the DBG_VALUE is live (or dead def) in the slot
index before the DBG_VALUE. If it isn't sane the DBG_VALUE is
discarded.

One pass that was identified as introducing non-sane DBG_VALUE
instructtons, when analysing pr36417, was the DAG->DAG Instruction
Selection. It sometimes inserts DBG_VALUE instructions referring to
a virtual register that is defined later in the same basic block.
So it is a use before def kind of problem. The DBG_VALUE is
typically inserted in the beginning of a basic block when this
happens. The problem can be seen in the test case
test/DebugInfo/X86/dbg-value-inlined-parameter.ll

Reviewers: aprantl, rnk, probinson

Reviewed By: aprantl

Subscribers: vsk, davide, alexcrichton, Ka-Ka, eraman, llvm-commits, JDevlieghere

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

llvm-svn: 326769

show more ...

[DebugInfo] Don't insert DEBUG_VALUE after terminators

r314974 introduced insertion of DEBUG_VALUEs after
each redefinition of debug value register in the slot index range.

In case the instruction

[DebugInfo] Don't insert DEBUG_VALUE after terminators

r314974 introduced insertion of DEBUG_VALUEs after
each redefinition of debug value register in the slot index range.

In case the instruction redefining the debug value register
was a terminator, machine verifier would complain since it
enforces the rule of no non-terminator instructions
following the first terminator.

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

llvm-svn: 324734

show more ...

[MachineOperand] Fix LiveDebugVariables code after isRenamable change.

Fix code in LiveDebugVariables that was changing def MachineOperands to
uses, which will hit an assert for dead operands after

[MachineOperand] Fix LiveDebugVariables code after isRenamable change.

Fix code in LiveDebugVariables that was changing def MachineOperands to
uses, which will hit an assert for dead operands after the change to add
the renamable bit to MachineOperands. Avoid the assert by clearing the
dead bit before changing the operand to a use.

Fixes issue reported in out of tree target by Jesper Antonsson at Ericsson.

llvm-svn: 321571

show more ...

MachineFunction: Return reference from getFunction(); NFC

The Function can never be nullptr so we can return a reference.

llvm-svn: 320884

Rename LiveIntervalAnalysis.h to LiveIntervals.h

Headers/Implementation files should be named after the class they
declare/define.

Also eliminated an `#include "llvm/CodeGen/LiveIntervalAnalysis.h"

Rename LiveIntervalAnalysis.h to LiveIntervals.h

Headers/Implementation files should be named after the class they
declare/define.

Also eliminated an `#include "llvm/CodeGen/LiveIntervalAnalysis.h"` in
favor of `class LiveIntarvals;`

llvm-svn: 320546

show more ...

[CodeGen] Unify MBB reference format in both MIR and debug output

As part of the unification of the debug format and the MIR format, print
MBB references as '%bb.5'.

The MIR printer prints the IR n

[CodeGen] Unify MBB reference format in both MIR and debug output

As part of the unification of the debug format and the MIR format, print
MBB references as '%bb.5'.

The MIR printer prints the IR name of a MBB only for block definitions.

* find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g'
* find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g'
* find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g'
* grep -nr 'BB#' and fix

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

llvm-svn: 319665

show more ...

Fix a bunch more layering of CodeGen headers that are in Target

All these headers already depend on CodeGen headers so moving them into
CodeGen fixes the layering (since CodeGen depends on Target, n

Fix a bunch more layering of CodeGen headers that are in Target

All these headers already depend on CodeGen headers so moving them into
CodeGen fixes the layering (since CodeGen depends on Target, not the
other way around).

llvm-svn: 318490

show more ...

Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layering

This header includes CodeGen headers, and is not, itself, included by
any Target headers, so move it into CodeGen to match the

Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layering

This header includes CodeGen headers, and is not, itself, included by
any Target headers, so move it into CodeGen to match the layering of its
implementation.

llvm-svn: 317647

show more ...

Reverting r315590; it did not include changes for llvm-tblgen, which is causing link errors for several people.

Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::

Reverting r315590; it did not include changes for llvm-tblgen, which is causing link errors for several people.

Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1

llvm-svn: 315854

show more ...

[dump] Remove NDEBUG from test to enable dump methods [NFC]

Summary:
Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with
LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.

Remove NDEBUG and

[dump] Remove NDEBUG from test to enable dump methods [NFC]

Summary:
Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with
LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.

Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods.

Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so
it'll be picked up by public headers.

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

llvm-svn: 315590

show more ...

[DebugInfo] Insert DEBUG_VALUEs after each register redefinition

Summary:
When reinserting debug values after register allocation, make sure to
insert debug values after each redefinition of debug v

[DebugInfo] Insert DEBUG_VALUEs after each register redefinition

Summary:
When reinserting debug values after register allocation, make sure to
insert debug values after each redefinition of debug value register in
the slot index range. The reason for this is that DwarfDebug will end
the range of a debug variable when the physical reg is defined. For
instructions with e.g. tied operands this result in prematurely ended
debug range.

This resolves pr34545

Patch by Karl-Johan Karlsson and Bjorn Pettersson

Reviewers: rnk, aprantl

Reviewed By: rnk

Subscribers: bjope, llvm-commits

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

llvm-svn: 314974

show more ...

Implement David Blaikie's suggestion for comparison operators

llvm-svn: 314822

[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

[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

show more ...

[DebugInfo] Do not extend range for physreg in LiveDebugVariables

Summary:
A DBG_VALUE that is referring to a physical register is
valid up until the next def of the register, or the end
of the basi

[DebugInfo] Do not extend range for physreg in LiveDebugVariables

Summary:
A DBG_VALUE that is referring to a physical register is
valid up until the next def of the register, or the end
of the basic block that it belongs to.

LiveDebugVariables is computing live intervals (slot index
ranges) for DBG_VALUE instructions, before regalloc, in order
to be able to re-insert DBG_VALUE instructions again after
regalloc. When the DBG_VALUE is mapping a variable to a
physical register we do not need to compute the range. We
should simply re-insert the DBG_VALUE at the start position.

The problem that was found, resulting in this patch, was a
situation when the DBG_VALUE was the last real use of the
physical register. The computeIntervals/extendDef methods
extended the range to cover the whole basic block, even though
the physical register very well could be allocated to some
virtual register inside the basic block. So the extended
range could not be trusted.

This patch is a preparation for https://reviews.llvm.org/D38229,
where the goal is to insert DBG_VALUE after each new definition
of a variable, even if the virtual registers that the variable
was connected to has been coalesced into using the same physical
register (e.g. due to two address instructions). For more info
see https://bugs.llvm.org/show_bug.cgi?id=34545

Reviewers: aprantl, rnk, echristo

Reviewed By: aprantl

Subscribers: Ka-Ka, llvm-commits

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

llvm-svn: 314414

show more ...

Cleanup some problems with LLVM_ENABLE_DUMP in release builds, and
always set LLVM_ENABLE_DUMP=ON for +Asserts builds.

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

llvm-svn: 314346

Re-land "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs"

After r313775, it's easier to maintain a parallel BitVector of spilled
locations indexed by location number.

I wasn't able

Re-land "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs"

After r313775, it's easier to maintain a parallel BitVector of spilled
locations indexed by location number.

I wasn't able to build a good reduced test case for this iteration of
the bug, but I added a more direct assertion that spilled values must
use frame index locations. If this bug reappears, it won't only fire on
the NEON vector code that we detected it on, but on medium-sized
integer-only programs as well.

llvm-svn: 313786

show more ...

[DebugInfo] Use a MapVector to coalesce MachineOperand locations

Summary:
The new code should be linear in the number of DBG_VALUEs, while the old
code was quadratic. NFC intended.

This is also hop

[DebugInfo] Use a MapVector to coalesce MachineOperand locations

Summary:
The new code should be linear in the number of DBG_VALUEs, while the old
code was quadratic. NFC intended.

This is also hopefully a more direct expression of the problem, which is
to:

1. Rewrite all virtual register operands to stack slots or physical
registers
2. Uniquely number those machine operands, assigning them location
numbers
3. Rewrite all uses of the old location numbers in the interval map to
use the new location numbers

In r313400, I attempted to track which locations were spilled in a
parallel bitvector indexed by location number. My code was broken
because these location numbers are not stable during rewriting.

Reviewers: aprantl, hans

Subscribers: hiraditya, llvm-commits

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

llvm-svn: 313775

show more ...

Revert "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs"

This reverts r313640, originally r313400, one more time for essentially
the same issue. My BitVector of spilled location num

Revert "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs"

This reverts r313640, originally r313400, one more time for essentially
the same issue. My BitVector of spilled location numbers isn't working
because we coalesce identical DBG_VALUE locations as we rewrite them,
invalidating the location numbers used to index the BitVector.

llvm-svn: 313679

show more ...

Re-land r313400 "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs"

I forgot to zero out the BitVector when reusing it between UserValues.

Later uses of the same location number for

Re-land r313400 "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs"

I forgot to zero out the BitVector when reusing it between UserValues.

Later uses of the same location number for a different UserValue would
falsely indicate that they were spilled. Usually this would lead to
incorrect debug info, but in some cases they would indicate something
nonsensical like a memory location based on a vector register (Q8 on
ARM).

llvm-svn: 313640

show more ...

Revert r313400 "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs"

This caused asserts in Chromium. See http://crbug.com/766261

> Summary:
> This comes up in optimized debug info for

Revert r313400 "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs"

This caused asserts in Chromium. See http://crbug.com/766261

> Summary:
> This comes up in optimized debug info for C++ programs that pass and
> return objects indirectly by address. In these programs,
> llvm.dbg.declare survives optimization, which causes us to emit indirect
> DBG_VALUE instructions. The fast register allocator knows to insert
> DW_OP_deref when spilling indirect DBG_VALUE instructions, but the
> LiveDebugVariables did not until this change.
>
> This fixes part of PR34513. I need to look into why this doesn't work at
> -O0 and I'll send follow up patches to handle that.
>
> Reviewers: aprantl, dblaikie, probinson
>
> Subscribers: qcolombet, hiraditya, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D37911

llvm-svn: 313589

show more ...

Name the sentinel value used for the location number of the undefined register NFC

llvm-svn: 313405

[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs

Summary:
This comes up in optimized debug info for C++ programs that pass and
return objects indirectly by address. In these programs

[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs

Summary:
This comes up in optimized debug info for C++ programs that pass and
return objects indirectly by address. In these programs,
llvm.dbg.declare survives optimization, which causes us to emit indirect
DBG_VALUE instructions. The fast register allocator knows to insert
DW_OP_deref when spilling indirect DBG_VALUE instructions, but the
LiveDebugVariables did not until this change.

This fixes part of PR34513. I need to look into why this doesn't work at
-O0 and I'll send follow up patches to handle that.

Reviewers: aprantl, dblaikie, probinson

Subscribers: qcolombet, hiraditya, llvm-commits

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

llvm-svn: 313400

show more ...

[CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 311703

[LiveDebugVariables] Use lexical scope to trim debug value live intervals

The debug value live intervals computed by Live Debug Variables may extend
beyond the range of the debug location's lexical

[LiveDebugVariables] Use lexical scope to trim debug value live intervals

The debug value live intervals computed by Live Debug Variables may extend
beyond the range of the debug location's lexical scope. In this case,
splitting of an interval can result in an interval outside of the scope being
created, causing extra unnecessary DBG_VALUEs to be emitted. To prevent this,
trim the intervals to the lexical scope.

This resolves PR33730.

Reviewers: aprantl

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

llvm-svn: 309933

show more ...