summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/LexicalScopes.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* MachineFunction: Return reference from getFunction(); NFCMatthias Braun2017-12-151-2/+2
| | | | | | The Function can never be nullptr so we can return a reference. llvm-svn: 320884
* Reverting r315590; it did not include changes for llvm-tblgen, which is ↵Aaron Ballman2017-10-151-1/+1
| | | | | | | | causing link errors for several people. Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1 llvm-svn: 315854
* [dump] Remove NDEBUG from test to enable dump methods [NFC]Don Hinton2017-10-121-1/+1
| | | | | | | | | | | | | | | Summary: Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP. Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods. Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so it'll be picked up by public headers. Differential Revision: https://reviews.llvm.org/D38406 llvm-svn: 315590
* Fixing an issue with the initialization of LexicalScopes objects when mixing ↵Wolfgang Pieb2017-07-191-1/+4
| | | | | | | | | | | | debug and non-debug units. Patch by Andrea DiBiagio. Differential Revision: https://reviews.llvm.org/D35637 llvm-svn: 308513
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* Don't generate line&scope debug info for meta-instructions.Adrian Prantl2017-05-221-2/+3
| | | | | | | | | | | | | | | MachineInstructions that don't generate any code (such as IMPLICIT_DEFs) should not generate any debug info either. Fixes PR33107. https://bugs.llvm.org/show_bug.cgi?id=33107 This reapplies r303566 without any modifications. The stage2 build failures persisted even after reverting this patch, and looking back through history, it looks like these tests are flaky. llvm-svn: 303575
* Revert "Don't generate line&scope debug info for meta-instructions."Adrian Prantl2017-05-221-3/+2
| | | | | | This reverts commit r303566 while investigating a stage2 buildbot failure. llvm-svn: 303570
* Don't generate line&scope debug info for meta-instructions.Adrian Prantl2017-05-221-2/+3
| | | | | | | | | | | MachineInstructions that don't generate any code (such as IMPLICIT_DEFs) should not generate any debug info either. Fixes PR33107. https://bugs.llvm.org/show_bug.cgi?id=33107 llvm-svn: 303566
* [CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-02-171-6/+13
| | | | | | other minor fixes (NFC). llvm-svn: 295499
* Handle link of NoDebug CU with a CU that has debug emission enabledTeresa Johnson2017-02-171-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This is an issue both with regular and Thin LTO. When we link together a DICompileUnit that is marked NoDebug (e.g when compiling with -g0 but applying an AutoFDO profile, which requires location tracking in the compiler) and a DICompileUnit with debug emission enabled, we can have failures during dwarf debug generation. Specifically, when we have inlined from the NoDebug compile unit into the debug compile unit, we can fail during construction of the abstract and inlined scope DIEs. This is because the SPMap does not include NoDebug CUs (they are skipped in the debug_compile_units_iterator). This patch fixes the failures by skipping locations from NoDebug CUs when extracting lexical scopes. Reviewers: dblaikie, aprantl Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D29765 llvm-svn: 295384
* Reformat slightly.Eric Christopher2017-02-141-4/+3
| | | | llvm-svn: 295096
* Cleanup dump() functions.Matthias Braun2017-01-281-4/+3
| | | | | | | | | | | | | | | | | | We had various variants of defining dump() functions in LLVM. Normalize them (this should just consistently implement the things discussed in http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html For reference: - Public headers should just declare the dump() method but not use LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) - The definition of a dump method should look like this: #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) LLVM_DUMP_METHOD void MyClass::dump() { // print stuff to dbgs()... } #endif llvm-svn: 293359
* 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
OpenPOWER on IntegriCloud