1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-23 04:52:54 +02:00
Commit Graph

896 Commits

Author SHA1 Message Date
Alp Toker
6580a45cd6 Fix typos
llvm-svn: 211304
2014-06-19 19:41:26 +00:00
David Blaikie
c27f5e5414 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.

llvm-svn: 211284
2014-06-19 17:59:14 +00:00
Alp Toker
4875e011e1 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.

llvm-svn: 211282
2014-06-19 17:15:36 +00:00
Oliver Stannard
0f096f23f1 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.

llvm-svn: 211272
2014-06-19 15:39:33 +00:00
Louis Gerbarg
c6a8e61725 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.

llvm-svn: 211130
2014-06-17 23:22:41 +00:00
Louis Gerbarg
7ea43963d7 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.

llvm-svn: 211052
2014-06-16 20:31:50 +00:00
Louis Gerbarg
55f89e91ff 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.

llvm-svn: 211040
2014-06-16 17:35:40 +00:00
David Blaikie
1043ced2ca 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).

llvm-svn: 210993
2014-06-15 19:34:26 +00:00
David Blaikie
a6798763a0 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.

llvm-svn: 210946
2014-06-13 22:35:44 +00:00
David Blaikie
33f6d6743b 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.

llvm-svn: 210943
2014-06-13 22:18:23 +00:00
David Blaikie
5712aace0c DebugInfo: Refactor some tests to allow DW_AT_name to not be the first attribute in a local variable.
In an effort to fix concrete variables referencing abstract origins
where the concrete variable preceeds the first inlined usage, the
addition of attributes such as name, file, etc will be delayed until the
end of the module (to wait to see if any inlined instances have
occurred, thus necessitating an abstract definition that the concrete
definition should also reference).

These test cases don't actually need to care about this ordering of
attributes, so update them to be more resilient to such changes coming
in the near future.

llvm-svn: 210940
2014-06-13 21:52:33 +00:00
David Blaikie
aedc8f92e6 test/DebugInfo/X86/dbg-value-isel.s: correct lexical block descriptor to match schema
This silently broke a long time ago when I unified some aspects of the
debug info schema. I'm just cleaning these up if/when they become a
problem.

llvm-svn: 210939
2014-06-13 21:52:28 +00:00
Alexey Samsonov
11cb912a27 [DWARF parser] Fix broken address ranges construction.
Previous algorithm for constructing [Address ranges]->[Compile Units]
mapping was wrong. It somewhat relied on the assumption that address ranges
for different compile units may not overlap. It is not so.
For example, two compile units may contain the definition of the same
linkonce_odr function. These definitions will be merged at link-time,
resulting in equivalent .debug_ranges entries for both these units

Instead of sorting and merging original address ranges (from .debug_ranges
and .debug_aranges), implement a different approach: save endpoints
of all ranges, and then use a sweep-line approach to construct
the desired mapping. If we find that certain address maps to
several compilation units, we just pick any of them.

llvm-svn: 210860
2014-06-12 23:58:49 +00:00
Alexey Samsonov
71917b612d [llvm-symbolizer] Fix parsing DW_AT_ranges in Fission skeleton compile unit DIEs.
Turns out that DW_AT_ranges_base attribute sets the offset for
DW_AT_ranges values specified in the .dwo file, but not for DW_AT_ranges specified
in the skeleton compile unit DIE in the main executable. This is extremely confusing,
and would hopefully be fixed in DWARF-5 when it's finalized. For now this
behavior makes sense, as otherwise Fission would break DWARF consumers who
doesn't know anything about DW_AT_ranges_base.

llvm-svn: 210809
2014-06-12 18:52:35 +00:00
Evgeniy Stepanov
340b2385c6 Improve the test for inlining of __no_debug__ functions.
llvm-svn: 210645
2014-06-11 08:46:45 +00:00
Alp Toker
03b6e12fae Reduce verbiage of lit.local.cfg files
We can just split targets_to_build in one place and make it immutable.

llvm-svn: 210496
2014-06-09 22:42:55 +00:00
Alexey Samsonov
e52f04f5e6 Generate better location ranges for some register-described variables.
Don't terminate location ranges for register-described variables
at the end of machine basic block if this register is never modified
in the function body, except for the prologue and epilogue. Prologue
location is guessed by FrameSetup flags on MachineInstructions, while
epilogue location is deduced from debug locations of instructions
in the basic blocks ending with return instructions.

This patch is mostly targeted to fix non-trivial debug locations for
variables addressed via stack and frame pointers.

It is not really a generic fix. We can still produce poor debug info
for register-described variables if this register *is* modified somewhere
in the function, but in unrelated places. This might be the case for the debug
info in optimized binaries (e.g. for local variables in inlined functions).
LiveDebugVariables pass in CodeGen attempts to fix this problem by adjusting
DBG_VALUE instructions, but this pass is tied to greedy register allocator,
which is used in optimized builds only. Proper fix would likely involve
generalizing LiveDebugVariables to all register allocators. See more discussion
in http://reviews.llvm.org/D3933 review thread.

I'm proceeding with this patch to fix immediate severe problems and
important cases, e.g. fix completely broken debug info with AddressSanitizer
and fix PR19307 (missing debug info for by-value std::string arguments).

llvm-svn: 210492
2014-06-09 21:53:47 +00:00
Evgeniy Stepanov
8af6942193 Fix line numbers for code inlined from __nodebug__ functions.
Instructions from __nodebug__ functions don't have file:line
information even when inlined into no-nodebug functions. As a result,
intrinsics (SSE and other) from <*intrin.h> clang headers _never_
have file:line information.

With this change, an instruction without !dbg metadata gets one from
the call instruction when inlined.

Fixes PR19001.

llvm-svn: 210459
2014-06-09 09:09:19 +00:00
Alp Toker
62946e907c Fix typos
llvm-svn: 210401
2014-06-07 21:23:09 +00:00
David Blaikie
77b762514c DebugInfo: Use the scope of the function declaration, if any, to name a function in DWARF pubnames
This ensures that member functions, for example, are entered into
pubnames with their fully qualified name, rather than inside the global
namespace.

llvm-svn: 210379
2014-06-06 22:29:05 +00:00
David Blaikie
2ad9dfbfdb DebugInfo: pubnames: include file-local (static or anonymous namespace) variables and anonymous namespaces themselves.
Still some issues with name qualification, FIXMEs added to test cases
and fixes will come next.

llvm-svn: 210378
2014-06-06 22:16:56 +00:00
David Blaikie
602e8bfac9 Match the full hex offsets in test/DebugInfo/X86/gnu-public-names.ll
These checks were accidentally skipping the 0x prefix in the hex
offsets, then cunningly ignoring the prefix in the use of those captured
values.

Except in the case of the unit length, where the match was only matching
the leading '0' before the x in the 0x prefix, then matching that
against the length. We can't actually express the length association
here, as the length field in the Compile Unit header does not include
the length field itself, but the length field in the pubnames section
/does/ include the size of the length field in the Compile Unit header -
so the two numbers are actually 4 bytes different. Just skip matching
that.

llvm-svn: 210364
2014-06-06 18:45:14 +00:00
David Blaikie
d9061de825 Remove DWARF3 testing of test/DebugInfo/X86/gnu-public-names.ll
This was added to test that DW_AT_GNU_pubnames used sec_offset in DWARF4
and data4 in DWARF3 and below. Since then we've updated
DW_AT_GNU_pubnames to be a flag, rather than a section offset anyway.

Granted this still differs between DWARF 3 and DWARF 4
(FORM_flag_present versun FORM_flag) but it doesn't seem worthwhile
testing that codepath again here. It's covered adequately in many other
test cases.

And while I'm here, don't hardcode the byte size of the compile unit -
it's not relevant to this test and just makes it brittle if/when
anything changes in the way this CU is emitted.

llvm-svn: 210362
2014-06-06 18:22:04 +00:00
Ulrich Weigand
506119853f XFAIL: test/DebugInfo/missing-abstract-variable.ll on s390x as well
llvm-svn: 210264
2014-06-05 14:20:54 +00:00
David Blaikie
c7bf52b36f PR19388: DebugInfo: Emit dead arguments in their originally declared order.
Unused arguments were not being added to the argument list, but instead
treated as arbitrary scope variables. This meant they weren't carefully
added in the original argument order.

In this particular example, though, it turns out the argument is only
/mostly/ unused (well, actually it's entirely used, but in a specific
way). It's a struct that, due to ABI reasons, is decomposed into chunks
(exactly one chunk, since it has one member) and then passed. Since only
one of those chunks is used (SROA, etc, kill the original reconstitution
code) we don't have a location to describe the whole variable.

In this particular case, since the struct consists of just the one int,
once we have partial location information, this should have a location
that describes the entire variable (since the piece is the entirety of
the object).

And at some point we'll need to describe the location of even /entirely/
unused arguments so that they can at least be printed on function entry.

llvm-svn: 210231
2014-06-05 00:51:35 +00:00
Alexey Samsonov
fd0b788d88 Use AArch64 instead of now removed ARM64 in test configs
llvm-svn: 210229
2014-06-05 00:25:30 +00:00
David Blaikie
06ac426ec0 DebugInfo: Reapply r209984 (reverted in r210143), asserting that abstract DbgVariables have DIEs.
Abstract variables within abstract scopes that are entirely optimized
away in their first inlining are omitted because their scope is not
present so the variable is never created. Instead, we should ensure the
scope is created so the variable can be added, even if it's been
optimized away in its first inlining.

This fixes the incorrect debug info in missing-abstract-variable.ll
(added in r210143) and passes an asserts self-hosting build, so
hopefully there's not more of these issues left behind... *fingers
crossed*.

llvm-svn: 210221
2014-06-04 23:50:52 +00:00
David Blaikie
7c97aca0c1 XFAIL: test/DebugInfo/missing-abstract-variable.ll on mips and ppc64 due to an inlined parameter that goes missing.
llvm-svn: 210200
2014-06-04 17:05:23 +00:00
David Blaikie
5a54fcae12 DebugInfo: Partial revert r209984 due to more cases where abstract DbgVariables do not have associated DIEs.
Along with a test case to demonstrate that due to inlining order there
are cases where abstract variable DIEs are not constructed since the
abstract subprogram was built due to a previous inlining that optimized
away those variables. This produces incorrect debug info (the 'missing'
abstract variable causes the inlined instance of that variable to be
emitted with a full description (name, line, file) rather than
referencing the abstract origin), but this commit at least ensures that
it doesn't crash...

llvm-svn: 210143
2014-06-04 01:30:59 +00:00
David Blaikie
365949d5af DebugInfo: Assert that DbgVariables have associated DIEs
This was previously committed in r209680 and reverted in r209683 after
it caused sanitizer builds to crash.

The issue seems to be that the DebugLoc associated with dbg.value IR
intrinsics isn't necessarily accurate. Instead, we duplicate the
DIVariables and add an InlinedAt field to them to record their
location.

We were using this InlinedAt field to compute the LexicalScope for the
variable, but not using it in the abstract DbgVariable construction and
mapping. This resulted in a formal parameter to the current concrete
function, correctly having no InlinedAt information, but incorrectly
having a DebugLoc that described an inlined location within the
function... thus an abstract DbgVariable was created for the variable,
but its DIE was never constructed (since the LexicalScope had no such
variable). This DbgVariable was silently ignored (by testing for a
non-null DIE on the abstract DbgVariable).

So, fix this by using the right scoping information when constructing
abstract DbgVariables.

In the long run, I suspect we want to undo the work that added this
second kind of location tracking and fix the places where the DebugLoc
propagation on the dbg.value intrinsic fails. This will shrink debug
info (by not duplicating DIVariables), make it more efficient (by not
having to construct new DIVariable metadata nodes to try to map back to
a single variable), and benefit all instructions.

But perhaps there are insurmountable issues with DebugLoc quality that
I'm unaware of... I just don't know how we can't /just keep the DebugLoc
from the dbg.declare to the dbg.values and never get this wrong/.

Some history context:

http://llvm.org/viewvc/llvm-project?view=revision&revision=135629
http://llvm.org/viewvc/llvm-project?view=revision&revision=137253

llvm-svn: 209984
2014-06-01 03:38:13 +00:00
Alp Toker
e8634eb077 Fix typos
llvm-svn: 209982
2014-05-31 21:26:28 +00:00
Arnaud A. de Grandmaison
a408079375 No need for those tests to go thru llvm-as and/or llvm-dis.
opt can handle them by itself.

llvm-svn: 209689
2014-05-27 22:03:28 +00:00
David Blaikie
54d2925f43 DebugInfo: Create abstract function definitions even when concrete definitions preceed inline definitions.
After much puppetry, here's the major piece of the work to ensure that
even when a concrete definition preceeds all inline definitions, an
abstract definition is still created and referenced from both concrete
and inline definitions.

Variables are still broken in this case (see comment in
dbg-value-inlined-parameter.ll test case) and will be addressed in
follow up work.

llvm-svn: 209677
2014-05-27 18:37:55 +00:00
David Blaikie
6003ac79b7 DebugInfo: Lazily construct subprogram definition DIEs.
A further step to correctly emitting concrete out of line definitions
preceeding inlined instances of the same program.

To do this, emission of subprograms must be delayed until required since
we don't know which (abstract only (if there's no out of line
definition), concrete only (if there are no inlined instances), or both)
DIEs are required at the start of the module.

To reduce the test churn in the following commit that actually fixes the
bug, this commit introduces the lazy DIE construction and cleans up test
cases that are impacted by the changes in the resulting DIE ordering.

llvm-svn: 209675
2014-05-27 18:37:48 +00:00
David Blaikie
ae911772eb DebugInfo: Lazily attach definition attributes to definitions.
This is a precursor to fixing inlined debug info where the concrete,
out-of-line definition may preceed any inlined usage. To cope with this,
the attributes that may appear on the concrete definition or the
abstract definition are delayed until the end of the module. Then, if an
abstract definition was created, it is referenced (and no other
attributes are added to the out-of-line definition), otherwise the
attributes are added directly to the out-of-line definition.

In a couple of cases this causes not just reordering of attributes, but
reordering of types. When the creation of the attribute is delayed, if
that creation would create a type (such as for a DW_AT_type attribute)
then other top level DIEs may've been constructed during the delay,
causing the referenced type to be created and added after those
intervening DIEs. In the extreme case, in cross-cu-inlining.ll, this
actually causes the DW_TAG_basic_type for "int" to move from one CU to
another.

llvm-svn: 209674
2014-05-27 18:37:43 +00:00
David Blaikie
c00f107068 DebugInfo: Fix argument ordering in test by adding argument numbering.
This old test didn't have the argument numbering that's now squirelled
away in the high bits of the line number in the DW_TAG_arg_variable
metadata.

Add the numbering and update the test to ensure arguments are in-order.

llvm-svn: 209669
2014-05-27 17:57:14 +00:00
David Blaikie
c035c9f443 DebugInfo: Test linkonce-odr functions under LTO.
This was previously regressed/broken by r192749 (reverted due to this
issue in r192938) and I was about to break it again by accident with
some more invasive changes that deal with the subprogram lists. So to
avoid that and further issues - here's a test.

It's a pretty basic test - in both r192749 and my impending case, this
test would crash, but checking the basics (that we put a subprogram in
just one of the two CUs) seems like a good start.

We still get this wrong in weird ways if the linkonce-odr function
happens to not be identical in the metadata (because it's defined in two
different files (hence the # line directives in this test), etc) even
though it meets the language requirements (identical token stream) for
such a thing. That results in two subprogram DIEs, but only one of them
gets the parameter and high/low pc information, etc. We probably need to
use the DIRef infrastructure to deduplicate functions as we do types to
address this issue - or perhaps teach the BC linker to remove the
duplicate entries in subprogram lists?

llvm-svn: 209614
2014-05-26 06:44:52 +00:00
David Blaikie
b1be374c2a DebugInfo: Fix inlining with #file directives a little harder
Seems my previous fix was insufficient - we were still not adding the
inlined function to the abstract scope list. Which meant it wasn't
flagged as inline, didn't have nested lexical scopes in the abstract
definition, and didn't have abstract variables - so the inlined variable
didn't reference an abstract variable, instead being described
completely inline.

llvm-svn: 209602
2014-05-25 18:11:35 +00:00
David Blaikie
ad221708ea Streamline test case by avoiding a temporary file and piping llc output straight to llvm-dwarfdump
We still do temporary files in many cases, just updating this particular
one because I was debugging it and made this change while doing so.

llvm-svn: 209601
2014-05-25 15:38:52 +00:00
Benjamin Kramer
bbbf511429 CodeGen: Make MachineBasicBlock::back skip to the beginning of the last bundle.
This makes front/back symmetric with begin/end, avoiding some confusion.
Added instr_front/instr_back for the old behavior, corresponding to
instr_begin/instr_end. Audited all three in-tree users of back(), all
of them look like they don't want to look inside bundles.

Fixes an assertion (PR19815) when generating debug info on mips, where a
delay slot was bundled at the end of a branch.

llvm-svn: 209580
2014-05-24 13:13:17 +00:00
Tim Northover
ca0f4dc4f0 AArch64/ARM64: move ARM64 into AArch64's place
This commit starts with a "git mv ARM64 AArch64" and continues out
from there, renaming the C++ classes, intrinsics, and other
target-local objects for consistency.

"ARM64" test directories are also moved, and tests that began their
life in ARM64 use an arm64 triple, those from AArch64 use an aarch64
triple. Both should be equivalent though.

This finishes the AArch64 merge, and everyone should feel free to
continue committing as normal now.

llvm-svn: 209577
2014-05-24 12:50:23 +00:00
Tim Northover
d7f173214f AArch64/ARM64: remove AArch64 from tree prior to renaming ARM64.
I'm doing this in two phases for a better "git blame" record. This
commit removes the previous AArch64 backend and redirects all
functionality to ARM64. It also deduplicates test-lines and removes
orphaned AArch64 tests.

The next step will be "git mv ARM64 AArch64" and rewire most of the
tests.

Hopefully LLVM is still functional, though it would be even better if
no-one ever had to care because the rename happens straight
afterwards.

llvm-svn: 209576
2014-05-24 12:42:26 +00:00
David Blaikie
02f43f4316 DebugInfo: Generalize some tests to handle variations in attribute ordering.
In an effort to fix inlined debug info in situations where the out of
line definition of a function preceeds any inlined usage, the order in
which some attributes are added to subprogram DIEs may change. (in
essence, definition-necessary attributes like DW_AT_low_pc/high_pc will
be added immediately, but the names, types, and other features will be
delayed to module end where they may either be added to the subprogram
DIE or instead reference an abstract definition for those values)

These tests can be generalized to be resilient to this change. 5 or so
tests actually have to be incompatibly changed to cope with this
reordering and will go along with the change that affects the order.

llvm-svn: 209554
2014-05-23 21:11:46 +00:00
David Blaikie
5c3adbbfc8 DebugInfo: Generalize a test case to not depend on abbreviation numbering.
It's an unnecessary detail for this test and just gets in the way when
making unrelated changes to the output in this test.

llvm-svn: 209553
2014-05-23 21:07:01 +00:00
David Blaikie
f42895705f DebugInfo: Put concrete definitions referencing abstract definitions in the same scope as the abstract definition.
This seems like a simple cleanup/improved consistency, but also helps
lay the foundation to fix the bug mentioned in the test case: concrete
definitions preceeding any inlined usage aren't properly split into
concrete + abstract (because they're not known to need it until it's too
late).

Once we start deferring this choice until later, we won't have the
choice to put concrete definitions for inlined subroutines in a
different scope from concrete definitions for non-inlined subroutines
(since we won't know at time-of-construction which one it'll be). This
change brings those two cases into alignment ahead of that future
chaneg/fix.

llvm-svn: 209547
2014-05-23 20:25:15 +00:00
David Blaikie
3765b7c1a0 DebugInfo: Fix cross-CU references for scopes (and variables within those scopes) in abstract definitions of cross-CU inlined functions
Found by Adrian Prantl during post-commit review of r209335.

llvm-svn: 209498
2014-05-23 04:23:06 +00:00
David Blaikie
a52d52f136 Revert "DebugInfo: Don't put fission type units in comdat sections."
This reverts commit r208930, r208933, and r208975.

It seems not all fission consumers are ready to handle this behavior.
Reverting until tools are brought up to spec.

llvm-svn: 209338
2014-05-21 23:27:41 +00:00
David Blaikie
f148b7f5aa DebugInfo: Use the SPMap to find the parent CU of inlined functions as they may not be in the current CU
Committed in r209178 then reverted in r209251 due to LTO breakage,
here's a proper fix for the case of the missing subprogram DIE. The DIEs
were there, just in other compile units. Using the SPMap we can find the
right compile unit to search for and produce cross-unit references to
describe this kind of inlining.

One existing test case needed to be updated because it had a function
that wasn't in the CU's subprogram list, so it didn't appear in the
SPMap.

llvm-svn: 209335
2014-05-21 23:14:12 +00:00
David Blaikie
03f45901f9 DebugInfo: Ensure concrete out of line variables from inlined functions reference their abstract origins.
llvm-svn: 209327
2014-05-21 22:41:17 +00:00
Eric Christopher
5039e6ecfc Move MCOptions that aren't shared between programs into their specific
program and have them initialize the MCOptions struct explicitly.

llvm-svn: 209321
2014-05-21 21:05:09 +00:00