Commit Graph

934 Commits

Author SHA1 Message Date
Juergen Ributzka
6398a7f5fd Revert several FastISel commits to track down a buildbot error.
This reverts:
r215595 "[FastISel][X86] Add large code model support for materializing floating-point constants."
r215594 "[FastISel][X86] Use XOR to materialize the "0" value."
r215593 "[FastISel][X86] Emit more efficient instructions for integer constant materialization."
r215591 "[FastISel][AArch64] Make use of the zero register when possible."
r215588 "[FastISel] Let the target decide first if it wants to materialize a constant."
r215582 "[FastISel][AArch64] Cleanup constant materialization code. NFCI."

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215673 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-14 19:56:28 +00:00
Juergen Ributzka
0701e5d43b [FastISel][X86] Use XOR to materialize the "0" value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215594 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-13 22:22:17 +00:00
Adrian Prantl
a6bd9bd30e DebugLocEntry: Restore the comparison predicate from before the
refactoring in 215384. This way it can unique multiple entries describing
the same piece even if they don't have the exact same location.
(The same piece may get merged in and be added from OpenRanges).
There ought to be a more elegant solution for this, though.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215418 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-12 01:07:53 +00:00
NAKAMURA Takumi
2477ef9014 Fix llvm/test/DebugInfo/X86/recursive_inlining.ll to use %llc_dwarf.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215181 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-08 02:24:05 +00:00
Adrian Prantl
7f48f056f7 Make these regexes stricter by disallowing any additional characters in the output.
Thanks to dblaikie for pointing this out!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215166 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-07 23:04:07 +00:00
Adrian Prantl
b93c57c0a9 Add a separate testcase for a DWARF expression describing a value in a
subregister.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215161 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-07 22:44:34 +00:00
David Blaikie
263998aa1d DebugInfo: Fix overwriting/loss of inlined arguments to recursively inlined functions.
Due to an unnecessary special case, inlined arguments that happened to
be from the same function as they were inlined into were misclassified
as non-inline arguments and would overwrite the non-inlined arguments.

Assert that we never overwrite a function's arguments, and stop
misclassifying inlined arguments as non-inline arguments to fix this
issue.

Excuse the rather crappy test case - handcrafted IR might do better, or
someone who understands better how to tickle the inliner to create a
recursive inlining situation like this (though it may also be necessary
to tickle the variable in a particular way to cause it to be recorded in
the MMI side table and go down this particular path for location
information).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215157 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-07 22:22:49 +00:00
Justin Bogner
971bf283f8 DebugInfo: Make a test more portable
mach-o doesn't like sections without segments, and elf is perfectly
happy with commas in section names, so use a Darwin-like section name.

Suggestion by Eric Christopher.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215052 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-07 03:47:28 +00:00
David Blaikie
e7a280ac86 DebugInfo: Fix ranges+gmlt test case to actually exercise the gmlt situation.
Originally this test case tested the specified behavior (that -gmlt
would not produce DW_AT_ranges and that when no CU DW_AT_ranges were
produced, no debug_ranges section (not even an empty list) would be
produced) but then the ranges emission code was improved not to create
ranges of a single element (instead favoring high_pc/low_pc) and so this
test case no longer exercised the -gmlt portion of the behavior.

This caused me some confusion when reading the comments and trying to
update this test case for future changes to -gmlt. I've made this test
resilient to those changes (by using the {{DW_TAG|NULL}} pattern to
block the end of the attribute search at the end of the CU's attribute
list without mandating that it must (or must not) be followed by another
tag (the future changes to -gmlt should produce no subprograms in this
CU))

Fix the test case to have two functions in distinct sections to force
the use of DW_AT_ranges.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214985 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-06 18:24:19 +00:00
David Blaikie
8480beefd0 DebugInfo: Assert that any CU for which debug_loc lists are emitted, has at least one range.
This was coming in weird debug info that had variables (and hence
debug_locs) but was in GMLT mode (because it was missing the 13th field
of the compile_unit metadata) so no ranges were constructed. We should
always have at least one range for any CU with a debug_loc in it -
because the range should cover the debug_loc.

The assertion just ensures that the "!= 1" range case inside the
subsequent loop doesn't get entered for the case where there are no
ranges at all, which should never reach here in the first place.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214939 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-06 00:21:25 +00:00
David Blaikie
406658c31b DebugInfo: Fix a bunch of tests that, owing to their compile_unit metadata not including a 13th field, had some subtle behavior.
Without the 13th field, the "emission kind" field defaults to 0 (which
is not equal to either of the values of the emission kind enum (1 ==
full debug info, 2 == line tables only)).

In this particular instance, the comparison with "FullDebugInfo" was
done when adding elements to the ranges list - so for these test cases
no values were added to the ranges list.

This got weirder when emitting debug_loc entries as the addresses should
be relative to the range of the CU if the CU has only one range (the
reasonable assumption is that if we're emitting debug_loc lists for a CU
that CU has at least one range - but due to the above situation, it has
zero) so the ranges were emitted relative to the start of the section
rather than relative to the start of the CU's singular range.

Fix these tests by accounting for the difference in the description of
debug_loc entries (in some cases making the test ignorant to these
differences, in others adding the extra label difference expression,
etc) or the presence/absence of high/low_pc on the CU, and add the 13th
field to their CUs to enable proper "full debug info" emission here.

In a future commit I'll fix up a bunch of other test cases that are not
so rigorously depending on this behavior, but still doing similarly
weird things due to the missing 13th field.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214937 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-05 23:57:31 +00:00
Adrian Prantl
65225b64bb Cleanup this test some more.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214591 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-01 23:01:32 +00:00
Adrian Prantl
22c6e043d1 Add the missing target triple to this testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214590 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-01 23:01:30 +00:00
Adrian Prantl
2a39c993eb Debug info: Infrastructure to support debug locations for fragmented
variables (for example, by-value struct arguments passed in registers, or
large integer values split across several smaller registers).
On the IR level, this adds a new type of complex address operation OpPiece
to DIVariable that describes size and offset of a variable fragment.
On the DWARF emitter level, all pieces describing the same variable are
collected, sorted and emitted as DWARF expressions using the DW_OP_piece
and DW_OP_bit_piece operators.

http://reviews.llvm.org/D3373
rdar://problem/15928306

What this patch doesn't do / Future work:
- This patch only adds the backend machinery to make this work, patches
  that change SROA and SelectionDAG's type legalizer to actually create
  such debug info will follow. (http://reviews.llvm.org/D2680)
- Making the DIVariable complex expressions into an argument of dbg.value
  will reduce the memory footprint of the debug metadata.
- The sorting/uniquing of pieces should be moved into DebugLocEntry,
  to facilitate the merging of multi-piece entries.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214576 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-01 22:11:58 +00:00
Rafael Espindola
d57120551f Use "weak alias" instead of "alias weak"
Before this patch we had

@a = weak global ...
but
@b = alias weak ...

The patch changes aliases to look more like global variables.

Looking at some really old code suggests that the reason was that the old
bison based parser had a reduction for alias linkages and another one for
global variable linkages. Putting the alias first avoided the reduce/reduce
conflict.

The days of the old .ll parser are long gone. The new one parses just "linkage"
and a later check is responsible for deciding if a linkage is valid in a
given context.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214355 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-30 22:51:54 +00:00
Manman Ren
23ab342d96 [Debug Info] remove DITrivialType and use null to represent unspecified param.
Per feedback on r214111, we are going to use null to represent unspecified
parameter. If the type array is {null}, it means a function that returns void;
If the type array is {null, null}, it means a variadic function that returns
void. In summary if we have more than one element in the type array and the last
element is null, it is a variadic function.

rdar://17628609


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214189 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 18:20:39 +00:00
Manman Ren
2bd885aa97 [Debug Info] unique MDNodes in the enum types of each compile unit.
The enum types array by design contains pointers to MDNodes rather than DIRefs.
Unique them when handling the enum types in DwarfDebug.

rdar://17628609


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214139 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 23:04:20 +00:00
David Blaikie
fcfd56262b Reapply "DebugInfo: Don't put fission type units in comdat sections."
This recommits r208930, r208933, and r208975 (by reverting r209338) and
reverts r209529 (the FIXME to readd this functionality once the tools
were fixed) now that DWP has been fixed to cope with a single section
for all fission type units.

Original commit message:

"Since type units in the dwo file are handled by a debug aware tool,
they don't need to leverage the ELF comdat grouping to implement
deduplication. Avoid creating all the .group sections for these as a
space optimization."

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213956 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 17:11:58 +00:00
David Blaikie
e27d5a0047 Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for functions that do not have top level debug information.
Reverted by Eric Christopher (Thanks!) in r212203 after Bob Wilson
reported LTO issues. Duncan Exon Smith and Aditya Nandakumar helped
provide a reduced reproduction, though the failure wasn't too hard to
guess, and even easier with the example to confirm.

The assertion that the subprogram metadata associated with an
llvm::Function matches the scope data referenced by the DbgLocs on the
instructions in that function is not valid under LTO. In LTO, a C++
inline function might exist in multiple CUs and the subprogram metadata
nodes will refer to the same llvm::Function. In this case, depending on
the order of the CUs, the first intance of the subprogram metadata may
not be the one referenced by the instructions in that function and the
assertion will fail.

A test case (test/DebugInfo/cross-cu-linkonce-distinct.ll) is added, the
assertion removed and a comment added to explain this situation.

This was then reverted again in r213581 as it caused PR20367. The root
cause of this was the early exit in LiveDebugVariables meant that
spurious DBG_VALUE intrinsics that referenced dead variables were not
removed, causing an assertion/crash later on. The fix is to have
LiveDebugVariables strip all DBG_VALUE intrinsics in functions without
debug info as they're not needed anyway. Test case added to cover this
situation (that occurs when a debug-having function is inlined into a
nodebug function) in test/DebugInfo/X86/nodebug_with_debug_loc.ll

Original commit message:

If a function isn't actually in a CU's subprogram list in the debug info
metadata, ignore all the DebugLocs and don't try to build scopes, track
variables, etc.

While this is possibly a minor optimization, it's also a correctness fix
for an incoming patch that will add assertions to LexicalScopes and the
debug info verifier to ensure that all scope chains lead to debug info
for the current function.

Fix up a few test cases that had broken/incomplete debug info that could
violate this constraint.

Add a test case where this occurs by design (inlining a
debug-info-having function in an attribute nodebug function - we want
this to work because /if/ the nodebug function is then inlined into a
debug-info-having function, it should be fine (and will work fine - we
just stitch the scopes up as usual), but should the inlining not happen
we need to not assert fail either).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213952 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 16:10:16 +00:00
David Blaikie
402cf195af DebugInfo: Fix up some test cases to have more correct debug info metadata.
* Add CUs to the named CU node
* Add missing DW_TAG_subprogram nodes
* Add llvm::Functions to the DW_TAG_subprogram nodes

This cleans up the tests so that they don't break under a
soon-to-be-made change that is more strict about such things.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213951 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 16:05:18 +00:00
David Blaikie
529165298e Revert "Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for functions that do not have top level debug information."
This reverts commit r212649 while I investigate/reduce/etc PR20367.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213581 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-21 20:45:59 +00:00
Saleem Abdulrasool
7be793b8cd MC: correct DWARF header for PE/COFF assembly input
The header contains an offset to the DWARF abbreviations for the CU.  The offset
must be section relative for COFF and absolute for others.  The non-assembly
code path for the DWARF header generation already had the correct emission for
the headers.  This corrects just the assembly path.  Due to the invalid
relocation, processing of the debug information would halt previously on the
first assembly input as the associated abbreviations would be out of range as
they would have the location increased by image base and the section offset.

This address PR20332.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213275 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-17 16:27:44 +00:00
David Blaikie
b930de10cd Try out FileCheck's new (in r212810) -implicit-check-not in a DebugInfo test.
Just tried this on a few tests and this was the only one that was
easily ported to use the new feature, so we'll go with that for now.
Hopefully can act as inspiration/reminder for other tests.

Not all debug info tests need to check for every DW_TAG or NULL child
terminator, but perhaps they should (just to ensure they don't accidentally
end up with tags nested inside other tags without the test failing, for example)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213092 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-15 21:06:37 +00:00
David Blaikie
9fe4d6bcd4 This test case doesn't actually need the inliner to reproduce the input.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212775 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-10 22:57:40 +00:00
Richard Sandiford
b350ec7ec6 [SystemZ] Fix FPR dwarf numbering
The dwarf FPR numbers are supposed to have the order F0, F2, F4, F6,
F1, F3, F5, F7, F8, etc., which matches the pairing of registers for
long doubles.  E.g. a long double stored in F0 is paired with F2.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212701 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-10 10:45:11 +00:00
David Blaikie
eff0c67b6a Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for functions that do not have top level debug information.
Reverted by Eric Christopher (Thanks!) in r212203 after Bob Wilson
reported LTO issues. Duncan Exon Smith and Aditya Nandakumar helped
provide a reduced reproduction, though the failure wasn't too hard to
guess, and even easier with the example to confirm.

The assertion that the subprogram metadata associated with an
llvm::Function matches the scope data referenced by the DbgLocs on the
instructions in that function is not valid under LTO. In LTO, a C++
inline function might exist in multiple CUs and the subprogram metadata
nodes will refer to the same llvm::Function. In this case, depending on
the order of the CUs, the first intance of the subprogram metadata may
not be the one referenced by the instructions in that function and the
assertion will fail.

A test case (test/DebugInfo/cross-cu-linkonce-distinct.ll) is added, the
assertion removed and a comment added to explain this situation.

Original commit message:

If a function isn't actually in a CU's subprogram list in the debug info
metadata, ignore all the DebugLocs and don't try to build scopes, track
variables, etc.

While this is possibly a minor optimization, it's also a correctness fix
for an incoming patch that will add assertions to LexicalScopes and the
debug info verifier to ensure that all scope chains lead to debug info
for the current function.

Fix up a few test cases that had broken/incomplete debug info that could
violate this constraint.

Add a test case where this occurs by design (inlining a
debug-info-having function in an attribute nodebug function - we want
this to work because /if/ the nodebug function is then inlined into a
debug-info-having function, it should be fine (and will work fine - we
just stitch the scopes up as usual), but should the inlining not happen
we need to not assert fail either).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212649 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-09 21:02:41 +00:00
Eric Christopher
3a3941576d Temporarily revert "Don't try to construct debug LexicalScopes hierarchy for functions that do not have top level debug information." as it appears to be breaking some LTO constructs.
This reverts commit r212203.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212298 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-03 22:24:54 +00:00
David Blaikie
a42211335a DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.
Originally committed in r211723, reverted in r211724 due to failure
cases found and fixed (ArgumentPromotion: r211872, Inlining: r212065),
committed again in r212085 and reverted again in r212089 after fixing
some other cases, such as debug info subprogram lists not keeping track
of the function they represent (r212128) and then short-circuiting
things like LiveDebugVariables that build LexicalScopes for functions
that might not have full debug info.

And again, I believe the invariant actually holds for some reasonable
amount of code (but I'll keep an eye on the buildbots and see what
happens... ).

Original commit message:

PR20038: DebugInfo: Inlined call sites where the caller has debug info
but the call itself has no debug location.

This situation does bad things when inlined, so I've fixed Clang not to
produce inlinable call sites without locations when the caller has debug
info (in the one case where I could find that this occurred). This
updates the PR20038 test case to be what clang now produces, and readds
the assertion that had to be removed due to this bug.

I've also beefed up the debug info verifier to help diagnose these
issues in the future, and I hope to add checks to the inliner to just
assert-fail if it encounters this situation. If, in the future, we
decide we have to cope with this situation, the right thing to do is
probably to just remove all the DebugLocs from the inlined instructions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212205 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-02 18:32:05 +00:00
David Blaikie
f9b6d0373a Don't try to construct debug LexicalScopes hierarchy for functions that do not have top level debug information.
If a function isn't actually in a CU's subprogram list in the debug info
metadata, ignore all the DebugLocs and don't try to build scopes, track
variables, etc.

While this is possibly a minor optimization, it's also a correctness fix
for an incoming patch that will add assertions to LexicalScopes and the
debug info verifier to ensure that all scope chains lead to debug info
for the current function.

Fix up a few test cases that had broken/incomplete debug info that could
violate this constraint.

Add a test case where this occurs by design (inlining a
debug-info-having function in an attribute nodebug function - we want
this to work because /if/ the nodebug function is then inlined into a
debug-info-having function, it should be fine (and will work fine - we
just stitch the scopes up as usual), but should the inlining not happen
we need to not assert fail either).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212203 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-02 18:31:35 +00:00
David Blaikie
74ed21faef Revert "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."
This reverts commit r212085.

This breaks the sanitizer bot... & I thought I'd tried pretty hard not
to do that. Guess I need to try harder.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212089 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-01 04:11:45 +00:00
David Blaikie
7186dd4513 DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.
Originally committed in r211723, reverted in r211724 due to failure
cases found and fixed (ArgumentPromotion: r211872, Inlining: r212065),
and I now believe the invariant actually holds for some reasonable
amount of code (but I'll keep an eye on the buildbots and see what
happens... ).

Original commit message:

PR20038: DebugInfo: Inlined call sites where the caller has debug info
but the call itself has no debug location.

This situation does bad things when inlined, so I've fixed Clang not to
produce inlinable call sites without locations when the caller has debug
info (in the one case where I could find that this occurred). This
updates the PR20038 test case to be what clang now produces, and readds
the assertion that had to be removed due to this bug.

I've also beefed up the debug info verifier to help diagnose these
issues in the future, and I hope to add checks to the inliner to just
assert-fail if it encounters this situation. If, in the future, we
decide we have to cope with this situation, the right thing to do is
probably to just remove all the DebugLocs from the inlined instructions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212085 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-01 03:11:59 +00:00
Adrian Prantl
93b97c9a57 Debug info: split out complex DIVariable address expressions into a
separate MDNode so they can be uniqued via folding set magic. To conserve
space, DIVariable nodes are still variable-length, with the last two
fields being optional.

No functional change.
http://reviews.llvm.org/D3526

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212050 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-30 17:17:35 +00:00
David Blaikie
0263debd04 Revert "Revert "Revert "PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location."""
Reverting this again, didn't mean to commit it - while r211872 fixes one
of the issues here, there are still others to figure out and address.

This reverts commit r211871.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211873 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-27 05:34:05 +00:00
David Blaikie
150f5b8920 Revert "Revert "PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location.""
This reverts commit r211724.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211871 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-27 05:31:49 +00:00
David Blaikie
276ef73f4a Revert "PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location."
This reverts commit r211723.

Breaks the ASan/compiler-rt build... guess I didn't test very far at all
:/.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211724 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-25 18:20:54 +00:00
David Blaikie
c39f36df61 PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location.
This situation does bad things when inlined, so I've fixed Clang not to
produce inlinable call sites without locations when the caller has debug
info (in the one case where I could find that this occurred). This
updates the PR20038 test case to be what clang now produces, and readds
the assertion that had to be removed due to this bug.

I've also beefed up the debug info verifier to help diagnose these
issues in the future, and I hope to add checks to the inliner to just
assert-fail if it encounters this situation. If, in the future, we
decide we have to cope with this situation, the right thing to do is
probably to just remove all the DebugLocs from the inlined instructions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211723 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-25 18:03:10 +00:00
Rafael Espindola
aa2e057bc1 Fix another asserting method in the null streamer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211668 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-25 05:37:58 +00:00
David Blaikie
639c71bafb Fix up scoping in a few tests (and delete one that validates unnecessary behavior).
Most of this is just tests that were silently succeeding in spite of
schema changes I made over a year ago. Cleaning them up as they lead to
failures in a change I'm working on/will come soon.

test/DebugInfo/2010-01-19-DbgScope.ll was removed as it tested miscoping
where a DebugLoc described a location not in the current function. The
test case doesn't describe why this is a valid situation and should be
supported, so I'm removing it and shortly going to commit changes that
make this firmly unsupported/assert-fail.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211628 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-24 20:10:27 +00:00
Rafael Espindola
e54c32ebc6 Move test so that it is skipped if the ARM target is not enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211366 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-20 15:30:38 +00:00
Rafael Espindola
61b696f1fa Allow a target to create a null streamer.
Targets can assume that a target streamer is present, so they have to be able
to construct a null streamer in order to set the target streamer in it to.

Fixes a crash when using the null streamer with arm.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211358 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-20 13:11:28 +00:00
Alp Toker
d06976aba7 Fix typos
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211304 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-19 19:41:26 +00:00
David Blaikie
6072096fd6 DebugInfo: Fission: Ensure the address pool entries for location lists are emitted.
The address pool was being emitted before location lists. The latter
could add more entries to the pool which would be lost/never emitted.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211284 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-19 17:59:14 +00:00
Alp Toker
36a321160e MCNullStreamer: assign file IDs to resolve crashes and errors
Use the MCStreamer base implementations for file ID tracking instead of
overriding them as no-ops.

Avoids assertions when streaming Dwarf debug info, and fixes ASM parsing of loc
and file directives.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211282 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-19 17:15:36 +00:00
Oliver Stannard
bb804ee909 Emit DWARF3 call frame information when DWARF3+ debug info is requested
Currently, llvm always emits a DWARF CIE with a version of 1, even when emitting
DWARF 3 or 4, which both support CIE version 3. This patch makes it emit the
newer CIE version when we are emitting DWARF 3 or 4. This will not reduce
compatibility, as we already emit other DWARF3/4 features, and is worth doing as
the DWARF3 spec removed some ambiguities in the interpretation of call frame
information.

It also fixes a minor bug where the "return address" field of the CIE was
encoded as a ULEB128, which is only valid when the CIE version is 3. There are
no test changes for this, because (as far as I can tell) none of the platforms
that we test have a return address register with a DWARF register number >127.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211272 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-19 15:39:33 +00:00
Louis Gerbarg
41b33299cf Allow X86FastIsel to cope with 64 bit absolute relocations
This patch is a follow up to r211040 & r211052. Rather than bailing out of fast
isel this patch will generate an alternate instruction (movabsq) instead of the
leaq. While this will always have enough room to handle the 64 bit displacment
it is generally over kill for internal symbols (most displacements will be
within 32 bits) but since we have no way of communicating the code model to the
the assmebler in order to avoid flagging an absolute leal/leaq as illegal when
using a symbolic displacement.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211130 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-17 23:22:41 +00:00
Louis Gerbarg
163eb0990c Improve comments for r211040
Added comment to clarify why we r211040 choose to bail out of fast isel instead
of generating a more complicated relocation, and fix mislabelled register in the
comments of the asan test case.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211052 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-16 20:31:50 +00:00
Louis Gerbarg
a564159d85 Fix illegal relocations in X86FastISel
On x86_86  the lea instruction can only use a 32 bit immediate value. When
the code is compiled statically the RIP register is not used, meaning the
immediate is all that can be used for the relocation, which is not sufficient
in the case of targets more than +/- 2GB away. This patch bails out of fast
isel in those cases and reverts to DAG which does the right thing.

Test case included.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211040 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-16 17:35:40 +00:00
David Blaikie
5379c6930d PR20038: DebugInfo missing DIEs for some concrete variables.
I haven't nailed this down entirely, but this is about as small of a
test case as I can seem to construct and adequately demonstrates the
crasher. I'll continue investigating the root cause/fix(es).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210993 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-15 19:34:26 +00:00
David Blaikie
f154f3b592 DebugInfo: Reference abstract definitions from variables in concrete definitions that preceed their first inline definition.
Rather than relying on abstract variables looked up at the time the
concrete variable is created, look them up at the end of the module to
ensure they're referenced even if they're created after the concrete
definition. This completes/matches the work done in r209677 to handle
this for the subprograms themselves.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210946 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-13 22:35:44 +00:00
David Blaikie
0fcb9cb1c1 DebugInfo: Following up to r209677, refactor local variable emission to delay the choice between emitting the definition attributes or using DW_AT_abstract_definition
This doesn't fix the abstract variable handling yet, but it introduces a
similar delay mechanism as was added for subprograms, causing
DW_AT_location to be reordered to the beginning of the attribute list
for local variables, and fixes all the test fallout for that.

A subsequent commit will remove the abstract variable handling in
DbgVariable and just do the abstract variable lookup at module end to
ensure that abstract variables introduced after their concrete
counterparts are appropriately referenced by the concrete variable.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210943 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-13 22:18:23 +00:00