summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/LexicalScopes.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Rewrite loops to use range-based for. (NFC)Adrian Prantl2016-09-281-17/+5
| | | | llvm-svn: 282608
* Fixed Dwarf debug info emission to skip DILexicalBlockFile entries.Amjad Aboud2016-04-211-7/+6
| | | | | | | | Before this fix, DILexicalBlockFile entries were skipped only in some cases and were not in other cases. Differential Revision: http://reviews.llvm.org/D18724 llvm-svn: 267004
* IR: Give 'DI' prefix to debug info metadataDuncan P. N. Exon Smith2015-04-291-24/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
* DebugInfo: Gut DISubprogram and DILexicalBlock*Duncan P. N. Exon Smith2015-04-141-2/+1
| | | | | | | Gut the `DIDescriptor` wrappers around `MDLocalScope` subclasses. Note that `DILexicalBlock` wraps `MDLexicalBlockBase`, not `MDLexicalBlock`. llvm-svn: 234850
* CodeGen: Stop using DIDescriptor::is*() and auto-castingDuncan P. N. Exon Smith2015-04-061-2/+2
| | | | | | Same as r234255, but for lib/CodeGen and lib/Target. llvm-svn: 234258
* DebugInfo: Remove LexicalBlockFile scope/context distinctionDuncan P. N. Exon Smith2015-03-311-12/+3
| | | | | | | | | | | | | | 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
* LexicalScopes: Cleanup remaining uses of DebugLocDuncan P. N. Exon Smith2015-03-301-8/+6
| | | | llvm-svn: 233644
* DebugLoc: Remove getFromDILexicalBlock()Duncan P. N. Exon Smith2015-03-301-10/+7
| | | | | | | | | 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
* LexicalScopes: Use debug info hierarchy pervasivelyDuncan P. N. Exon Smith2015-03-301-30/+38
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* LexicalScopes: Use MDLocation directly instead of DebugLocDuncan P. N. Exon Smith2015-03-301-12/+10
| | | | | | | 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
* CodeGen: Use the new DebugLoc API, NFCDuncan P. N. Exon Smith2015-03-301-14/+10
| | | | | | Update lib/CodeGen (and lib/Target) to use the new `DebugLoc` API. llvm-svn: 233582
* AsmPrinter: Stop creating DebugLocsDuncan P. N. Exon Smith2015-02-171-8/+0
| | | | | | | | | | | | | | | | 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
* MSVC 2013 supports std::forward_as_tuple, while MSVC 2012 did not; so we can ↵Aaron Ballman2015-02-161-10/+8
| | | | | | move to using the improved API. llvm-svn: 229414
* DebugInfo: Ensure that all debug location scope chains from instructions ↵David Blaikie2014-10-141-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Fix stuff... again."David Blaikie2014-10-141-7/+2
| | | | | | | | Accidental commit. This reverts commit r219693. llvm-svn: 219695
* Fix stuff... again.David Blaikie2014-10-141-2/+7
| | | | llvm-svn: 219693
* Revert "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-10-101-7/+2
| | | | | | | | | | | 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
* DebugInfo: Ensure that all debug location scope chains from instructions ↵David Blaikie2014-10-071-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-1/+1
| | | | | | needing to mention the size. llvm-svn: 216158
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-181-1/+1
| | | | | | | | 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 ↵Craig Topper2014-08-171-1/+1
| | | | | | needing to mention the size. llvm-svn: 215868
* Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-08-061-7/+2
| | | | | | | | | | | 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
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-08-041-2/+7
| | | | | | | | | | | | | | 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
* Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from ↵Eric Christopher2014-07-181-7/+2
| | | | | | | | | | 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
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-181-2/+7
| | | | | | | | | | | | | | | | | 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
* Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-111-7/+2
| | | | | | | | | | | | 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
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-101-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-021-7/+2
| | | | | | | | | | | | 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
* DebugInfo: Ensure that all debug location scope chains from instructions ↵David Blaikie2014-07-021-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-011-7/+2
| | | | | | | | | | | 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. llvm-svn: 212089
* DebugInfo: Ensure that all debug location scope chains from instructions ↵David Blaikie2014-07-011-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 212085
* Revert "Revert "Revert "PR20038: DebugInfo: Inlined call sites where the ↵David Blaikie2014-06-271-7/+2
| | | | | | | | | | | 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. llvm-svn: 211873
* Revert "Revert "PR20038: DebugInfo: Inlined call sites where the caller has ↵David Blaikie2014-06-271-2/+7
| | | | | | | | debug info but the call itself has no debug location."" This reverts commit r211724. llvm-svn: 211871
* Revert "PR20038: DebugInfo: Inlined call sites where the caller has debug ↵David Blaikie2014-06-251-7/+2
| | | | | | | | | | | 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 :/. llvm-svn: 211724
* PR20038: DebugInfo: Inlined call sites where the caller has debug info but ↵David Blaikie2014-06-251-2/+7
| | | | | | | | | | | | | | | | | | 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: 211723
* DebugInfo: Fix inlining with #file directives a little harderDavid Blaikie2014-05-251-5/+5
| | | | | | | | | | | 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
* Recommit r208506: DebugInfo: Include lexical scopes in inlined subroutines.David Blaikie2014-05-141-12/+27
| | | | | | | | | | | | | | | | | | | | This was reverted in r208642 due to regressions surrounding file changes within lexical scopes causing inlining information to be lost. The issue was in LexicalScopes::getOrCreateInlinedScope, where I was previously testing "isLexicalBlock" which is false for "DILexicalBlockFile" (a scope used to represent changes in the current file name) and assuming it was then a function (breaking out of the inlined scope path and reaching for the parent non-inlined scopes). By inverting the condition and testing for "isSubprogram" the correct behavior is attained. (also found some weirdness in Clang, see r208742 when reducing this test case - the resulting test case doesn't apply with the Clang fix, but I've added a more realistic test case to inline-scopes.ll which does reproduce the issue and demonstrate the fix) llvm-svn: 208748
* Revert "DebugInfo: Include lexical scopes in inlined subroutines."David Blaikie2014-05-121-28/+12
| | | | | | | | | This reverts commit r208506. Some inlined subroutine scopes appear to be missing with this change. Reverting while I investigate. llvm-svn: 208642
* DebugInfo: Include lexical scopes in inlined subroutines.David Blaikie2014-05-111-12/+28
| | | | llvm-svn: 208506
* Reapply r207876 (Try simplifying LexicalScopes ownership again) including a ↵David Blaikie2014-05-081-28/+35
| | | | | | | | | | | | | | | | | | | workaround for an MSVC2012 bug regarding forward_as_tuple (r207876 was reverted in r208131 after seeing some consistent buildbot failure for MSVC 2012. The original commits were in r207724-r207726) Takumi was nice enough to dig into this and locate this Microsoft Connect issue: http://connect.microsoft.com/VisualStudio/feedback/details/814899/forward-as-tuple-debug-implementation-error describing a bug in MSVC2012's forward_as_tuple implementation. Since the parameters in this instance are trivial/small, pass them by value (using make_tuple) instead of perfectly-forwarded tuple of rvalue references (involving the broken forward_as_tuple). Hopefully this will satisfy MSVC2012. llvm-svn: 208364
* Revert "Try simplifying LexicalScopes ownership again."David Blaikie2014-05-061-32/+28
| | | | | | | | | Speculatively reverting due to a suspicious failure on a Windows buildbot. This reverts commit 10c37a012ea11596d44cd9059fe09c959caf30c8. llvm-svn: 208131
* Try simplifying LexicalScopes ownership again.David Blaikie2014-05-021-28/+32
| | | | | | | | | | | | | | Committed initially in r207724-r207726 and reverted due to compiler-rt crashes in r207732. Instead, fix this harder with unordered_map and store the LexicalScopes by value in the map. This did necessitate moving the definition of LexicalScope above the definition of LexicalScopes. Let's see how the buildbots/compilers tolerate unordered_map::emplace + std::piecewise_construct + std::forward_as_tuple... llvm-svn: 207876
* Speculatively roll back r207724-r207726, which are code cleanup changes andRichard Smith2014-05-011-30/+25
| | | | | | appear to be breaking a bootstrapped build of compiler-rt. llvm-svn: 207732
* LexicalScopes: Use unique_ptr to manage ownership of abstract LexicalScopes.David Blaikie2014-04-301-8/+9
| | | | llvm-svn: 207726
* Forgotten reformatting.David Blaikie2014-04-301-5/+9
| | | | llvm-svn: 207725
* LexicalScopes: use unique_ptr to own LexicalScope objects.David Blaikie2014-04-301-16/+16
| | | | | | Ownership of abstract scopes coming soon. llvm-svn: 207724
* Convert more loops to range-based equivalentsAlexey Samsonov2014-04-301-10/+7
| | | | llvm-svn: 207714
* Convert several loops over MachineFunction basic blocks to range-based loopsAlexey Samsonov2014-04-301-6/+4
| | | | llvm-svn: 207683
* [Modules] Remove potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | | | | | | define below all header includes in the lib/CodeGen/... tree. While the current modules implementation doesn't check for this kind of ODR violation yet, it is likely to grow support for it in the future. It also removes one layer of macro pollution across all the included headers. Other sub-trees will follow. llvm-svn: 206837
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-141-14/+14
| | | | | | instead of comparing to nullptr. llvm-svn: 206142
OpenPOWER on IntegriCloud