Support for DW_FORM_implicit_const DWARFv5 feature.
When this form is used attribute value goes to .debug_abbrev section (as SLEB).
As this form would break any debug tool which doesn't support DWARFv5
it is guarded by dwarf version check. Attempt to use this form with
dwarf version <= 4 is considered a fatal error.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291599 91177308-0d34-0410-b5e6-96231b3b80d8

order to avoid jumpy line tables. Calls are left alone because they may be inlined.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291258 91177308-0d34-0410-b5e6-96231b3b80d8

This reapplies r289828 (reverted in r289833 as it broke the address sanitizer).  The
debugloc is now only set when the instruction is not a call, as this causes the
verifier to assert (the inliner requires an inlinable callsite to have a debug loc
if the caller and callee have debug info).

Original commit message:

Simplify CFG will try to sink the last instruction in a series of basic blocks,
creating a "common" instruction in the successor block (sinkLastInstruction).
When it does this, the debug location of the single instruction should be the
merged debug locations of the commoned instructions.

Original review: https://reviews.llvm.org/D27590


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290973 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
In mergeSPUpdates, debug values need to be ignored when getting the
previous element, otherwise debug data could have an impact on codegen.

In eliminateCallFramePseudoInstr, debug values after the erased element
could have an impact on codegen and should be skipped.

Closes PR31319 (https://llvm.org/bugs/show_bug.cgi?id=31319)

Reviewers: aprantl, MatzeB, mkuper

Subscribers: gbedwell, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290955 91177308-0d34-0410-b5e6-96231b3b80d8

This reapplies rL289013 (reverted in rL289014) with the fixes identified
in D21731. Should hopefully pass the buildbots this time.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290809 91177308-0d34-0410-b5e6-96231b3b80d8

This fixes the issue exposed in PR31393, where we weren't trying
sufficiently hard to diagnose bad TBAA metadata.

This does reduce the variety in the error messages we print out, but I
think the tradeoff of verifying more, simply and quickly overrules the
need for more helpful error messags here.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290713 91177308-0d34-0410-b5e6-96231b3b80d8

When DwarfExpression is emitting a fragment that is located in a
register and that fragment is smaller than the register, and the
register must be composed from sub-registers (are you still with me?)
the last DW_OP_piece operation must not be larger than the size of the
fragment itself, since the last piece of the fragment could be smaller
than the last subregister that is being emitted.

rdar://problem/29779065

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290324 91177308-0d34-0410-b5e6-96231b3b80d8

This patch renumbers the metadata nodes in debug info testcases after
https://reviews.llvm.org/D26769. This is a separate patch because it
causes so much churn. This was implemented with a python script that
pipes the testcases through llvm-as - | llvm-dis - and then goes
through the original and new output side-by side to insert all
comments at a close-enough location.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290292 91177308-0d34-0410-b5e6-96231b3b80d8

This patch implements PR31013 by introducing a
DIGlobalVariableExpression that holds a pair of DIGlobalVariable and
DIExpression.

Currently, DIGlobalVariables holds a DIExpression. This is not the
best way to model this:

(1) The DIGlobalVariable should describe the source level variable,
    not how to get to its location.

(2) It makes it unsafe/hard to update the expressions when we call
    replaceExpression on the DIGLobalVariable.

(3) It makes it impossible to represent a global variable that is in
    more than one location (e.g., a variable with multiple
    DW_OP_LLVM_fragment-s).  We also moved away from attaching the
    DIExpression to DILocalVariable for the same reasons.

This reapplies r289902 with additional testcase upgrades and a change
to the Bitcode record for DIGlobalVariable, that makes upgrading the
old format unambiguous also for variables without DIExpressions.

<rdar://problem/29250149>
https://llvm.org/bugs/show_bug.cgi...

Feedback on r289468 from Adrian Prantl.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290012 91177308-0d34-0410-b5e6-96231b3b80d8

The original patch was broken due to some undefined behavior
as well as warnings that were triggering -Werror.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290000 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit 289920 (again).
I forgot to implement a Bitcode upgrade for the case where a DIGlobalVariable
has not DIExpression. Unfortunately it is not possible to safely upgrade
these variables without adding a flag to the bitcode record indicating which
version they are.
My plan of record is to roll the planned follow-up patch that adds a
unit: field to DIGlobalVariable into this patch before recomitting.
This way we only need one Bitcode upgrade for both changes (with a
version flag in the bitcode record to safely distinguish the record
formats).

Sorry for the churn!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289982 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit r289978, which is failing due to some rebase/merge
issues.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289981 91177308-0d34-0410-b5e6-96231b3b80d8

This is the 3rd of 3 patches to get reading and writing of
CodeView symbol and type records to use a single codepath.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289978 91177308-0d34-0410-b5e6-96231b3b80d8

Reverting because this breaks lld's gdb_index support - it's probably
double counting the abbrev relocation offset.

This reverts commit r289954.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289961 91177308-0d34-0410-b5e6-96231b3b80d8

Input can be produced by ld -r, for example (a normal LLVM workflow
never hits this - LLVM only ever produces a single abbrev table in an
object (shared by multiple CUs), so the reloc's always 0, and when it's
linked together the relocation's resolved so it doesn't need to be
handled)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289954 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289944 91177308-0d34-0410-b5e6-96231b3b80d8

One more attempt to re-commit the patch r285355, which I had to revert in r285362, because some tests were failing (the reason is because the size of the line_table varied depending on the full file name).

In the past the compiler always emitted .debug_line version 2, though some opcodes from DWARF 3 (e.g. DW_LNS_set_prologue_end, DW_LNS_set_epilogue_begin or DW_LNS_set_isa) and from DWARF 4 could be emitted by the compiler.

This patch changes version information of .debug_line to exactly match the DWARF version. For .debug_line version 4, a new field maximum_operations_per_instruction is emitted.

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289925 91177308-0d34-0410-b5e6-96231b3b80d8

This patch implements PR31013 by introducing a
DIGlobalVariableExpression that holds a pair of DIGlobalVariable and
DIExpression.

Currently, DIGlobalVariables holds a DIExpression. This is not the
best way to model this:

(1) The DIGlobalVariable should describe the source level variable,
    not how to get to its location.

(2) It makes it unsafe/hard to update the expressions when we call
    replaceExpression on the DIGLobalVariable.

(3) It makes it impossible to represent a global variable that is in
    more than one location (e.g., a variable with multiple
    DW_OP_LLVM_fragment-s).  We also moved away from attaching the
    DIExpression to DILocalVariable for the same reasons.

This reapplies r289902 with additional testcase upgrades.

<rdar://problem/29250149>
https://llvm.org/bugs/show_bug.cgi?id=31013
Differential Revision: https://reviews.llvm.org/D26769

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289920 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit 289902 while investigating bot berakage.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289906 91177308-0d34-0410-b5e6-96231b3b80d8

This patch implements PR31013 by introducing a
DIGlobalVariableExpression that holds a pair of DIGlobalVariable and
DIExpression.

Currently, DIGlobalVariables holds a DIExpression. This is not the
best way to model this:

(1) The DIGlobalVariable should describe the source level variable,
    not how to get to its location.

(2) It makes it unsafe/hard to update the expressions when we call
    replaceExpression on the DIGLobalVariable.

(3) It makes it impossible to represent a global variable that is in
    more than one location (e.g., a variable with multiple
    DW_OP_LLVM_fragment-s).  We also moved away from attaching the
    DIExpression to DILocalVariable for the same reasons.

<rdar://problem/29250149>
https://llvm.org/bugs/show_bug.cgi?id=31013
Differential Revision: https://reviews.llvm.org/D26769

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289902 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289893 91177308-0d34-0410-b5e6-96231b3b80d8

This seems more consistent, and helps tidy up/simplify some other code
in this change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289889 91177308-0d34-0410-b5e6-96231b3b80d8

Reverting as it is causing buildbot failures (address sanitizer).



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289833 91177308-0d34-0410-b5e6-96231b3b80d8

Simplify CFG will try to sink the last instruction in a series of basic blocks,
creating a "common" instruction in the successor block (sinkLastInstruction).
When it does this, the debug location of the single instruction should be the
merged debug locations of the commoned instructions.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289828 91177308-0d34-0410-b5e6-96231b3b80d8

If all the operands to a phi node are compares that have a RHS constant,
instcombine will try to pull them through the phi node, combining them into
a single operation. When it does this, the debug location of the new op
should be the merged debug locations of the phi node arguments.

Patch 8 of 8 for D26256.  Folding of a compare that has a RHS constant.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289704 91177308-0d34-0410-b5e6-96231b3b80d8

If all the operands to a phi node are a binop with a RHS constant, instcombine
will try to pull them through the phi node, combining them into a single
operation. When it does this, the debug location of the new op should be the
merged debug locations of the phi node arguments.

Patch 7 of 8 for D26256.  Folding of a binop with RHS constant.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289699 91177308-0d34-0410-b5e6-96231b3b80d8

If all the operands to a phi node are a cast, instcombine will try to pull
them through the phi node, combining them into a single cast. When it does
this, the debug location of the new cast should be the merged debug locations
of the phi node arguments.

Patch 6 of 8 for D26256.  Folding of a cast operation.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289693 91177308-0d34-0410-b5e6-96231b3b80d8

If all the operands to a phi node are a load, instcombine will try to pull
them through the phi node, combining them into a single load. When it does
this, the debug location of the new load should be the merged debug locations
of the phi node arguments.

Patch 5 of 8 for D26256.  Folding of a load operation.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289688 91177308-0d34-0410-b5e6-96231b3b80d8

If all the operands to a phi node are getelementptr, instcombine
will try to pull them through the phi node, combining them into a single
operation.  When it does this, the debug location of the new getelementptr
should be the merged debug locations of the phi node arguments.

Patch 4 of 8 for D26256.  Folding of a getelementptr operation.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289684 91177308-0d34-0410-b5e6-96231b3b80d8

If all the operands to a phi node are of the same operation, instcombine
will try to pull them through the phi node, combining them into a single
operation.  When it does this, the debug location of the operation should
be the merged debug locations of the phi node arguments.

Patch 3 of 8 for D26256.  Folding of a compare operation.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289681 91177308-0d34-0410-b5e6-96231b3b80d8

If all the operands to a phi node are of the same operation, instcombine
will try to pull them through the phi node, combining them into a single
operation.  When it does this, the debug location of the operation should
be the merged debug locations of the phi node arguments.

Patch 2 of 8 for D26256.  Folding of a binary operation.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289679 91177308-0d34-0410-b5e6-96231b3b80d8

Follow-up to r289256, address a FIXME to avoid resetting the column
number. This reduced .debug_line by 2.6% in a RelWithDebInfo
self-build of clang.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289620 91177308-0d34-0410-b5e6-96231b3b80d8

DWARF specifies that "line 0" really means "no appropriate source
location" in the line table.  By default, use this for branch targets
and some other cases that have no specified source location, to
prevent inheriting unfortunate line numbers from physically preceding
instructions (which might be from completely unrelated source).

Updated patch allows enabling or suppressing this behavior for all
unspecified source locations.

Differential Revision: http://reviews.llvm.org/D24180


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289468 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289288 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289281 91177308-0d34-0410-b5e6-96231b3b80d8

LLVM's use of DW_OP_bit_piece is incorrect and a based on a
misunderstanding of the wording in the DWARF specification. The offset
argument of DW_OP_bit_piece refers to the offset into the location
that is on the top of the DWARF expression stack, and not an offset
into the source variable. This has since also been clarified in the
DWARF specification.

This patch fixes all uses of DW_OP_bit_piece to emit the correct
offset and simplifies the DwarfExpression class to semi-automaticaly
emit empty DW_OP_pieces to adjust the offset of the source variable,
thus simplifying the code using DwarfExpression.

While this is an incompatible bugfix, in practice I don't expect this
to be much of a problem since LLVM's old interpretation and the
correct interpretation of DW_OP_bit_piece differ only when there are
gaps in the fragmented locations of the described variables or if
individual fragments are smaller than a byte. LLDB at least won't
interpret locations with gaps in them because is has no way to present
undefined bits in a variable, and there is a high probability that an
old-form expression will be malformed when interpreted correctly,
because the DW_OP_bit_piece offset will be outside of the location at
the top of the stack.

As a nice side-effect, this patch enables us to use a more efficient
encoding for subregisters: In order to express a sub-register at a
non-zero offset we now use a DW_OP_bit_piece instead of shifting the
value into place manually.

This patch also adds missing test coverage for code paths that weren't
exercised before.

<rdar://problem/29335809>
Differential Revision: https://reviews.llvm.org/D27550

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289266 91177308-0d34-0410-b5e6-96231b3b80d8

Like DBG_VALUE, these emit nothing to the .text section, and sometimes
have no source location specified.  Just ignore them.

Differential Revision: http://reviews.llvm.org/D27492


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289256 91177308-0d34-0410-b5e6-96231b3b80d8

Appears to break on build bots. Reverting pending investigation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289014 91177308-0d34-0410-b5e6-96231b3b80d8

The relocations for `DIEEntry::EmitValue` were wrong for Win64
(emitting FK_Data_4 instead of FK_SecRel_4). This corrects that
oversight so that the DWARF data is correct in Win64 COFF files.

Fixes PR15393.

Patch by Jameson Nash <jameson@juliacomputing.com> based on a patch
by David Majnemer.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289013 91177308-0d34-0410-b5e6-96231b3b80d8