CodeGen: Stop using DIDescriptor::is*() and auto-casting

Same as r234255, but for lib/CodeGen and lib/Target.

llvm-svn: 234258

DebugInfo: Remove LexicalBlockFile scope/context distinction

Two things here:

1. I read `getScope()` and `getContext()` backwards in r233640. There
was no need for `getScopeOfScope()`. Obvio

DebugInfo: Remove LexicalBlockFile scope/context distinction

Two things here:

1. I read `getScope()` and `getContext()` backwards in r233640. There
was no need for `getScopeOfScope()`. Obviously not enough test
coverage here (as I said in that commit, I'm going to come back to
that), but anyway I'm reverting to the behaviour before r233640.
2. The callers that use `DILexicalBlockFile::getContext()` don't seem
to care about the difference. Just have it redirect to `getScope()`
so I can't get confused again.

llvm-svn: 233650

show more ...

LexicalScopes: Cleanup remaining uses of DebugLoc

llvm-svn: 233644

DebugLoc: Remove getFromDILexicalBlock()

The only user of `DebugLoc::getFromDILexicalBlock()` was creating a new
`MDLocation` as convenient API for passing an `MDScope`. Stop doing
that, and remove

DebugLoc: Remove getFromDILexicalBlock()

The only user of `DebugLoc::getFromDILexicalBlock()` was creating a new
`MDLocation` as convenient API for passing an `MDScope`. Stop doing
that, and remove the API. If in the future we actually *want* to create
new DebugLocs, calling `MDLexicalBlock::get()` makes more sense.

llvm-svn: 233643

show more ...

LexicalScopes: Use debug info hierarchy pervasively

Pervasively use the types provided by the debug info hierarchy rather
than `MDNode` in `LexicalScopes`.

I noticed (again, I guess, based on comme

LexicalScopes: Use debug info hierarchy pervasively

Pervasively use the types provided by the debug info hierarchy rather
than `MDNode` in `LexicalScopes`.

I noticed (again, I guess, based on comments in the implementation?)
that `DILexicalBlockFile::getScope()` returns something different from
`DILexicalBlockFile::getContext()`. I created a local helper for
getting the same logic from `MDLexicalBlockFile` called
`getScopeOfScope()`. I still don't really understand it, but I've added
some FIXMEs and I'll come back to it (I suspect the way we encode these
objects isn't really ideal).

Note that my previous commit r233610 accidentally changed behaviour in
`findLexicalScope()` -- it transitioned from a call to
`DILexicalBlockFile::getScope()` to `MDLexicalBlockFile::getScope()`
(sounds right, doesn't it?) -- so I've fixed that as a drive-by. No
tests failed with my error, so it looks like we're missing some coverage
here... when I come back to understand the logic, I'll see if I can add
some.

Other than the fix to `findLexicalScope()`, no functionality change.

llvm-svn: 233640

show more ...

LexicalScopes: Use MDLocation directly instead of DebugLoc

There's no benefit to using `DebugLoc` here. Moreover, this will let a
follow-up commit work with `MDScope` directly instead of `DebugLoc`

LexicalScopes: Use MDLocation directly instead of DebugLoc

There's no benefit to using `DebugLoc` here. Moreover, this will let a
follow-up commit work with `MDScope` directly instead of `DebugLoc`.

llvm-svn: 233610

show more ...

CodeGen: Use the new DebugLoc API, NFC

Update lib/CodeGen (and lib/Target) to use the new `DebugLoc` API.

llvm-svn: 233582

AsmPrinter: Stop creating DebugLocs

While looking at a heap profile of a clang LTO bootstrap with -g, I
noticed that 2.2% of memory in an `llvm-lto` of clang is from calling
`DebugLoc::get()` in `co

AsmPrinter: Stop creating DebugLocs

While looking at a heap profile of a clang LTO bootstrap with -g, I
noticed that 2.2% of memory in an `llvm-lto` of clang is from calling
`DebugLoc::get()` in `collectVariableInfo()` (accounting for ~40% of
memory used for `MDLocation`s).

I suspect this was introduced by r226736, whose goal was to prevent
uniquing of `DebugLoc`s (goal achieved, if so).

There's no reason we need a `DebugLoc` here at all -- it was just being
used for (in)convenient API -- so the fix is to pass the scope and
inlined-at directly to `LexicalScopes::findInlinedScope()`.

llvm-svn: 229459

show more ...

MSVC 2013 supports std::forward_as_tuple, while MSVC 2012 did not; so we can move to using the improved API.

llvm-svn: 229414

DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.

Let me tell you a tale...

Originally committed in r211723 after discovering

DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.

Let me tell you a tale...

Originally committed in r211723 after discovering a nasty case of weird
scoping due to inlining, this was reverted in r211724 after it fired in
ASan/compiler-rt.

(minor diversion where I accidentally committed/reverted again in
r211871/r211873)

After further testing and fixing bugs in ArgumentPromotion (r211872) and
Inlining (r212065) it was recommitted in r212085. Reverted in r212089
after the sanitizer buildbots still showed problems.

Fixed another bug in ArgumentPromotion (r212128) found by this
assertion.

Recommitted in r212205, reverted in r212226 after it crashed some more
on sanitizer buildbots.

Fix clang some more in r212761.

Recommitted in r212776, reverted in r212793. ASan failures.
Recommitted in r213391, reverted in r213432, trying to reproduce flakey
ASan build failure.

Fixed bugs in r213805 (ArgPromo + DebugInfo), r213952
(LiveDebugVariables strips dbg_value intrinsics in functions not
described by debug info).

Recommitted in r214761, reverted in r214999, flakey failure on Windows
buildbot.

Fixed DeadArgElimination + DebugInfo bug in r219210.

Recommitted in r219215, reverted in r219512, failure on ObjC++ atomic
properties in the test-suite on Darwin.

Fixed ObjC++ atomic properties issue in Clang in r219690.

[This commit is provided 'as is' with no hope that this is the last time
I commit this change either expressed or implied]

llvm-svn: 219702

show more ...

Revert "Fix stuff... again."

Accidental commit.

This reverts commit r219693.

llvm-svn: 219695

Fix stuff... again.

llvm-svn: 219693

Revert "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."

This invariant is violated (& the assertions fire) on some Objective

Revert "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."

This invariant is violated (& the assertions fire) on some Objective C++
in the test-suite. Reverting while I investigate.

This reverts commit r219215.

llvm-svn: 219523

show more ...

DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.

Let me tell you a tale...

Originally committed in r211723 after discovering

DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.

Let me tell you a tale...

Originally committed in r211723 after discovering a nasty case of weird
scoping due to inlining, this was reverted in r211724 after it fired in
ASan/compiler-rt.

(minor diversion where I accidentally committed/reverted again in
r211871/r211873)

After further testing and fixing bugs in ArgumentPromotion (r211872) and
Inlining (r212065) it was recommitted in r212085. Reverted in r212089
after the sanitizer buildbots still showed problems.

Fixed another bug in ArgumentPromotion (r212128) found by this
assertion.

Recommitted in r212205, reverted in r212226 after it crashed some more
on sanitizer buildbots.

Fix clang some more in r212761.

Recommitted in r212776, reverted in r212793. ASan failures.
Recommitted in r213391, reverted in r213432, trying to reproduce flakey
ASan build failure.

Fixed bugs in r213805 (ArgPromo + DebugInfo), r213952
(LiveDebugVariables strips dbg_value intrinsics in functions not
described by debug info).

Recommitted in r214761, reverted in r214999, flakey failure on Windows
buildbot.

Fixed DeadArgElimination + DebugInfo bug in r219210.

Recommitting and hoping that's the last of it.

[That one burned down, fell over, then sank into the swamp.]

llvm-svn: 219215

show more ...

Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid needing to mention the size.

llvm-svn: 216158

Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid needing to mention the size."

Getting a weird buildbot failure that I need to investigate.

llvm-svn: 215870

Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid needing to mention the size.

llvm-svn: 215868

Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.""

This reverts commit r214761.

Revert while Reid investigat

Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.""

This reverts commit r214761.

Revert while Reid investigates & provides a reproduction for an
assertion failure for this on Windows.

llvm-svn: 214999

show more ...

Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."

Originally reverted in r213432 with flakey failures on an ASan self

Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."

Originally reverted in r213432 with flakey failures on an ASan self-host
build. After reduction it seems to be the same issue fixed in r213805
(ArgPromo + DebugInfo: Handle updating debug info over multiple
applications of argument promotion) and r213952 (by having
LiveDebugVariables strip dbg_value intrinsics in functions that are not
described by debug info). Though I cannot explain why this failure was
flakey...

llvm-svn: 214761

show more ...

Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.""""

After a successful build it seems to have come back on a

Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.""""

After a successful build it seems to have come back on a later build.

This reverts commit r213391.

llvm-svn: 213432

show more ...

Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."""

Recommits 212776 which was reverted in r212793. This has been com

Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."""

Recommits 212776 which was reverted in r212793. This has been committed
and recommitted a few times as I try to test it harder and find/fix more
issues. The most recent revert was due to an asan bot failure which I
can't seem to reproduce locally, though I believe I'm following all the
steps the buildbot does.

So I'm going to recommit this in the hopes of investigating the failure
on the buildbot itself... apologies in advance for the bot noise. If
anyone sees failures with this /please/ provide me with any
reproductions, etc.

llvm-svn: 213391

show more ...

Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.""

This reverts commit r212776.

Nope, still seems to be fail

Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.""

This reverts commit r212776.

Nope, still seems to be failing on the sanitizer bots... but hey, not
the msan self-host anymore, it's failing in asan now. I'll start looking
there next.

llvm-svn: 212793

show more ...

Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."

Committed in r212205 and reverted in r212226 due to msan self-hosti

Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."

Committed in r212205 and reverted in r212226 due to msan self-hosting
failure, I believe I've got that fixed by r212761 to Clang.

Original commit message:

"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."

llvm-svn: 212776

show more ...

Revert "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."

This reverts commit r212205.

Reverting this again, still seeing cra

Revert "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."

This reverts commit r212205.

Reverting this again, still seeing crashes when building compiler-rt...
Sorry for the continued noise, not sure why I'm failing to reproduce
this locally.

llvm-svn: 212226

show more ...

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 fou

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.

llvm-svn: 212205

show more ...