| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 230206
|
|
|
|
| |
llvm-svn: 230193
|
|
|
|
| |
llvm-svn: 230188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parse (and write) symbolic constants in debug info `flags:` fields.
This prevents a readability (and CHECK-ability) regression with the new
debug info hierarchy.
Old (well, current) assembly, with pretty-printing:
!{!"...\\0016387", ...} ; ... [public] [rvalue reference]
Flags field without this change:
!MDDerivedType(flags: 16387, ...)
Flags field with this change:
!MDDerivedType(flags: DIFlagPublic | DIFlagRValueReference, ...)
As discussed in the review thread, this isn't a final state. Most of
these flags correspond to `DW_AT_` symbolic constants, and we might
eventually want to support arbitrary attributes in some form. However,
as it stands now, some of the flags correspond to other concepts (like
`FlagStaticMember`); until things are refactored this is the simplest
way to move forward without regressing assembly.
llvm-svn: 230111
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the old (well, current) schema, there are two types of file
references: untagged and tagged (the latter references the former).
!0 = !{!"filename", !"/directory"}
!1 = !{!"0x29", !1} ; DW_TAG_file_type [filename] [/directory]
The interface to `DIBuilder` universally takes the tagged version,
described by `DIFile`. However, most `file:` references actually use
the untagged version directly.
In the new hierarchy, I'm merging this into a single node: `MDFile`.
Originally I'd planned to keep the old schema unchanged until after I
moved the new hierarchy into place.
However, it turns out to be trivial to make `MDFile` match both nodes at
the same time.
- Anyone referencing !1 does so through `DIFile`, whose implementation
I need to gut anyway (as I do the rest of the `DIDescriptor`s).
- Anyone referencing !0 just references an `MDNode`, and expects a
node with two `MDString` operands.
This commit achieves that, and updates all the testcases for the parts
of the new hierarchy that used the two-node schema (I've replaced the
untagged nodes with `distinct !{}` to make the diff clear (otherwise the
metadata all gets renumbered); it might be worthwhile to come back and
delete those nodes and renumber the world, not sure).
llvm-svn: 230057
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When writing the bitcode serialization for the new debug info hierarchy,
I assumed two fields would never be null.
Drop that assumption, since it's brittle (and crashes the
`BitcodeWriter` if wrong), and is a check better left for the verifier
anyway. (No need for a bitcode upgrade here, since the new hierarchy is
still not in place.)
The fields in question are `MDCompileUnit::getFile()` and
`MDDerivedType::getBaseType()`, the latter of which isn't null in
test/Transforms/Mem2Reg/ConvertDebugInfo2.ll (see !14, a pointer to
nothing). While the testcase might have bitrotted, there's no reason
for the bitcode format to rely on non-null for metadata operands.
This also fixes a bug in `AsmWriter` where if the `file:` is null it
isn't emitted (caught by the double-round trip in the testcase I'm
adding) -- this is a required field in `LLParser`.
I'll circle back to ConvertDebugInfo2. Once the specialized nodes are
in place, I'll be trying to turn the debug info verifier back on by
default (in the newer module pass form committed r206300) and throwing
more logic in there. If the testcase has bitrotted (as opposed to me
not understanding the schema correctly) I'll fix it then.
llvm-svn: 229960
|
|
|
|
|
|
|
|
|
| |
When trying to match the current schema with the new debug info
hierarchy, I downgraded `SizeInBits`, `AlignInBits` and `OffsetInBits`
to 32-bits (oops!). Caught this while testing my upgrade script to move
the hierarchy into place. Bump it back up to 64-bits and update tests.
llvm-svn: 229933
|
|
|
|
|
|
|
|
|
|
| |
Follow-up to r229740, which removed `DITemplate*::getContext()` after my
upgrade script revealed that scopes are always `nullptr` for template
parameters. This is the other shoe: drop `scope:` from
`MDTemplateParameter` and its two subclasses. (Note: a bitcode upgrade
would be pointless, since the hierarchy hasn't been moved into place.)
llvm-svn: 229791
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that `count: -1` is a special value indicating an empty
array, such as `Values` in:
struct T {
unsigned Count;
int Values[];
};
Handle it.
llvm-svn: 229769
|
|
|
|
|
|
|
|
|
| |
Put the name before the value in assembly for `MDEnum`. While working
on the testcase upgrade script for the new hierarchy, I noticed that it
"looks nicer" to have the name first, since it lines the names up in the
(somewhat typical) case that they have a common prefix.
llvm-svn: 229747
|
|
|
|
| |
llvm-svn: 229420
|
|
|
|
|
|
| |
Cast validity depends on the cast's kind, not just its types.
llvm-svn: 229366
|
|
|
|
| |
llvm-svn: 229365
|
|
|
|
| |
llvm-svn: 229364
|
|
|
|
| |
llvm-svn: 229363
|
|
|
|
| |
llvm-svn: 229356
|
|
|
|
| |
llvm-svn: 229355
|
|
|
|
| |
llvm-svn: 229354
|
|
|
|
| |
llvm-svn: 229025
|
|
|
|
| |
llvm-svn: 229024
|
|
|
|
| |
llvm-svn: 229023
|
|
|
|
| |
llvm-svn: 229022
|
|
|
|
| |
llvm-svn: 229020
|
|
|
|
| |
llvm-svn: 229019
|
|
|
|
| |
llvm-svn: 229018
|
|
|
|
| |
llvm-svn: 229017
|
|
|
|
| |
llvm-svn: 229016
|
|
|
|
| |
llvm-svn: 229015
|
|
|
|
| |
llvm-svn: 229014
|
|
|
|
| |
llvm-svn: 229013
|
|
|
|
| |
llvm-svn: 229011
|
|
|
|
| |
llvm-svn: 229010
|
|
|
|
| |
llvm-svn: 229009
|
|
|
|
| |
llvm-svn: 229007
|
|
|
|
| |
llvm-svn: 229006
|
|
|
|
| |
llvm-svn: 229005
|
|
|
|
| |
llvm-svn: 229004
|
|
|
|
| |
llvm-svn: 229003
|
|
|
|
|
|
| |
An alloca's type should be weird things like metadata.
llvm-svn: 228820
|
|
|
|
| |
llvm-svn: 228819
|
|
|
|
| |
llvm-svn: 228813
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove unnecessary restriction of 24-bits for line numbers in
`MDLocation`.
The rest of the debug info schema (with the exception of local
variables) uses 32-bits for line numbers. As I introduce the
specialized nodes, it makes sense to canonicalize on one size or the
other.
llvm-svn: 228455
|
|
|
|
|
|
|
| |
Recognize `DW_TAG_` constants in assembly, and output it by default for
`GenericDebugNode`.
llvm-svn: 228042
|
|
|
|
| |
llvm-svn: 228041
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During `MDNode::deleteTemporary()`, call `replaceAllUsesWith(nullptr)`
to update all tracking references to `nullptr`.
This fixes PR22280, where inverted destruction order between tracking
references and the temporaries themselves caused a use-after-free in
`LLParser`.
An alternative fix would be to add an assertion that there are no users,
and continue to fix inverted destruction order in clients (like
`LLParser`), but instead I decided to make getting-teardown-right easy.
(If someone disagrees let me know.)
llvm-svn: 226866
|
|
|
|
| |
llvm-svn: 226524
|
|
|
|
|
|
| |
Raise the limit for column information from 8 bits to 16 bits.
llvm-svn: 226291
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit moves `MDLocation`, finishing off PR21433. There's an
accompanying clang commit for frontend testcases. I'll attach the
testcase upgrade script I used to PR21433 to help out-of-tree
frontends/backends.
This changes the schema for `DebugLoc` and `DILocation` from:
!{i32 3, i32 7, !7, !8}
to:
!MDLocation(line: 3, column: 7, scope: !7, inlinedAt: !8)
Note that empty fields (line/column: 0 and inlinedAt: null) don't get
printed by the assembly writer.
llvm-svn: 226048
|
|
|
|
|
|
| |
Print `MDLocation`'s `line` field even when it's 0.
llvm-svn: 226046
|
|
|
|
| |
llvm-svn: 226012
|