summaryrefslogtreecommitdiff
path: root/llvm/lib/IR/DebugLoc.cpp
AgeCommit message (Collapse)Author
2025-11-05[NFC][LLVM][IR] Cleanup namespace usage in LLVM IR cpp files (#166477)Rahul Joshi
2025-09-10[DebugInfo] When merging locations prefer unannotated empty locs (#157707)Stephen Tozer
When merging DILocations, we prefer to use DebugLoc::getMergedLocation when possible to better preserve DebugLoc coverage tracking information through transformations (as conversion to DILocations drops all coverage tracking data). Currently, DebugLoc::getMergedLocation checks to see if either DebugLoc is empty and returns it directly if so, to propagate that DebugLoc's coverage tracking data to the merged location; however, it only checks whether either location is valid, not whether they are annotated. This is significant because an annotated location is not a bug, while an empty unannotated location may be one; therefore, we check to see if either location is unannotated, and prefer to return that location if it exists rather than an annotated one. This change is NFC outside of DebugLoc coverage tracking builds.
2025-07-03 [DLCov] Origin-Tracking: Collect stack traces in DebugLoc (#146678)Stephen Tozer
This patch is part of a series that adds origin-tracking to the debugify source location coverage checks, allowing us to report symbolized stack traces of the point where missing source locations appear. This patch adds the logic for collecting stack traces in DebugLoc instances. We do not symbolize the stack traces in this patch - that only happens when we decide to actually print them, which will be the responsibility of debugify. The collection happens in the constructor of a DebugLoc that has neither a valid location nor an annotation; we also collect an extra stack trace every time we call setDebugLoc, as sometimes the more interesting point is not where the DebugLoc was constructed, but where it was applied to an instruction. This takes the form of a getCopied() method on DebugLoc, which is the identity function in normal builds, but adds an extra stack trace in origin-tracking builds.
2025-06-16[build] Fixed LLVM_ENABLE_DEBUGLOC_COVERAGE_TRACKING handling. (#144391)Slava Zakharin
Change in #107278 modified the CMake CACHE variable with values that are not supported for it as documented. This patch renames the derived vars so that they do not conflict with the CACHE variable.
2025-06-12[DLCov][NFC] Propagate annotated DebugLocs through transformations (#138047)Stephen Tozer
Part of the coverage-tracking feature, following #107279. In order for DebugLoc coverage testing to work, we firstly have to set annotations for intentionally-empty DebugLocs, and secondly we have to ensure that we do not drop these annotations as we propagate DebugLocs throughout compilation. As the annotations exist as part of the DebugLoc class, and not the underlying DILocation, they will not survive a DebugLoc->DILocation->DebugLoc roundtrip. Therefore this patch modifies a number of places in the compiler to propagate DebugLocs directly rather than via the underlying DILocation. This has no effect on the output of normal builds; it only ensures that during coverage builds, we do not drop incorrectly annotations and therefore create false positives. The bulk of these changes are in replacing DILocation::getMergedLocation(s) with a DebugLoc equivalent, and in changing the IRBuilder to store a DebugLoc directly rather than storing DILocations in its general Metadata array. We also use a new function, `DebugLoc::orElse`, which selects the "best" DebugLoc out of a pair (valid location > annotated > empty), preferring the current DebugLoc on a tie - this encapsulates the existing behaviour at a few sites where we _may_ assign a DebugLoc to an existing instruction, while extending the logic to handle annotation DebugLocs at the same time.
2025-05-06[KeyInstr] Inline atom info (#133481)Orlando Cazalet-Hyams
Source atom groups are identified by an atom group number and inlined-at pair, so we simply can copy the atom numbers into the caller when inlining. RFC: https://discourse.llvm.org/t/rfc-improving-is-stmt-placement-for-better-interactive-debugging/82668
2025-04-30Reapply "[DLCov] Implement DebugLoc coverage tracking (#107279)"Stephen Tozer
Reapplied after fixing the config issue that was causing issues following the previous merge. This reverts commit fdbf073a86573c9ac4d595fac8e06d252ce1469f.
2025-04-25Revert "[DLCov] Implement DebugLoc coverage tracking (#107279)"Stephen Tozer
This reverts commit a9d93ecf1f8d2cfe3f77851e0df179b386cff353. Reverted due to the commit including a config in LLVM headers that is not available outside of the llvm source tree.
2025-04-24[DLCov] Implement DebugLoc coverage tracking (#107279)Stephen Tozer
This is part of a series of patches that tries to improve DILocation bug detection in Debugify; see the review for more details. This is the patch that adds the main feature, adding a set of `DebugLoc::get<Kind>` functions that can be used for instructions with intentionally empty DebugLocs to prevent Debugify from treating them as bugs, removing the currently-pervasive false positives and allowing us to use Debugify (in its original DI preservation mode) to reliably detect existing bugs and regressions. This patch does not add uses of these functions, except for once in Clang before optimizations, and in `Instruction::dropLocation()`, since that is an obvious case that immediately removes a set of false positives.
2022-12-12[nfc][DebugInfo] Move subprogram rewriting utility to headerFelipe de Azevedo Piovezan
This utility will be useful in subsequent patches, as such we expose it in the DebugInfoMetadata header. Depends on D139669 Differential Revision: https://reviews.llvm.org/D139670
2022-12-06[CodeExtractor] Correctly propagate scope information post extractionFelipe de Azevedo Piovezan
When a new function "NewF" is created with instructions extracted from another function "OldF", the CodeExtractor only preserves debug line/column of the extracted instructions. However: 1. Any inlinedAt nodes are dropped. 2. The scope chain is replaced with a single node, the Subprogram of NewF. Both of these are incorrect: most of the debug metadata from the original instructions should be preserved. We only need to update the Subprogram found at the scope of the last node of the inline chain; this Subprogram used to be OldF but now should be NewF. Differential Revision: https://reviews.llvm.org/D139217
2022-02-02Cleanup header dependencies in LLVMCoreserge-sans-paille
Based on the output of include-what-you-use. This is a big chunk of changes. It is very likely to break downstream code unless they took a lot of care in avoiding hidden ehader dependencies, something the LLVM codebase doesn't do that well :-/ I've tried to summarize the biggest change below: - llvm/include/llvm-c/Core.h: no longer includes llvm-c/ErrorHandling.h - llvm/IR/DIBuilder.h no longer includes llvm/IR/DebugInfo.h - llvm/IR/IRBuilder.h no longer includes llvm/IR/IntrinsicInst.h - llvm/IR/LLVMRemarkStreamer.h no longer includes llvm/Support/ToolOutputFile.h - llvm/IR/LegacyPassManager.h no longer include llvm/Pass.h - llvm/IR/Type.h no longer includes llvm/ADT/SmallPtrSet.h - llvm/IR/PassManager.h no longer includes llvm/Pass.h nor llvm/Support/Debug.h And the usual count of preprocessed lines: $ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/IR/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l before: 6400831 after: 6189948 200k lines less to process is no that bad ;-) Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D118652
2021-01-08[IR] Delete unused ReplaceLast in DebugLoc::appendInlineAtFangrui Song
Not used after r304488
2020-12-15[IR] Delete deprecated DebugLoc::getFangrui Song
2020-12-11Migrate deprecated DebugLoc::get to DILocation::getFangrui Song
This migrates all LLVM (except Kaleidoscope and CodeGen/StackProtector.cpp) DebugLoc::get to DILocation::get. The CodeGen/StackProtector.cpp usage may have a nullptr Scope and can trigger an assertion failure, so I don't migrate it. Reviewed By: #debug-info, dblaikie Differential Revision: https://reviews.llvm.org/D93087
2020-07-01Pass DebugLoc::appendInlinedAt DebugLoc arg by const reference not value.Simon Pilgrim
Noticed by clang-tidy performance-unnecessary-value-param warning.
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
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
2018-09-20[IR] Add a boolean field in DILocation to know if a line must covered or notCalixte Denizet
Summary: Some lines have a hit counter where they should not have one. For example, in C++, some cleanup is adding at the end of a scope represented by a '}'. So such a line has a hit counter where a user expects to not have one. The goal of the patch is to add this information in DILocation which is used to get the covered lines in GCOVProfiling.cpp. A following patch in clang will add this information when generating IR (https://reviews.llvm.org/D49916). Reviewers: marco-c, davidxl, vsk, javed.absar, rnk Reviewed By: rnk Subscribers: eraman, xur, danielcdh, aprantl, rnk, dblaikie, #debug-info, vsk, llvm-commits, sylvestre.ledru Tags: #debug-info Differential Revision: https://reviews.llvm.org/D49915 llvm-svn: 342631
2018-04-30IWYU for llvm-config.h in llvm, additions.Nico Weber
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
2018-03-15Use standard `print(dbgs())` pattern to implement DebugLoc::dumpSean Silva
The open-coded implementation had a bug. It didn't print filenames. llvm-svn: 327681
2017-12-13Remove redundant includes from lib/IR.Michael Zolotukhin
llvm-svn: 320622
2017-10-15Reverting r315590; it did not include changes for llvm-tblgen, which is ↵Aaron Ballman
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
2017-10-12[dump] Remove NDEBUG from test to enable dump methods [NFC]Don Hinton
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
2017-06-06Sort the remaining #include lines in include/... and lib/....Chandler Carruth
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
2017-06-01Reapply "[Cloning] Take another pass at properly cloning debug info"Keno Fischer
This was rL304226, reverted in 304228 due to a clang assertion failure on the build bots. That problem should have been addressed by clang commit rL304470. llvm-svn: 304488
2017-05-30Revert "[Cloning] Take another pass at properly cloning debug info"Keno Fischer
At least one build bot is complaining. Will investigate after lunch. llvm-svn: 304228
2017-05-30[Cloning] Take another pass at properly cloning debug infoKeno Fischer
Summary: In rL302576, DISubprograms gained the constraint that a !dbg attachments to functions must have a 1:1 mapping to DISubprograms. As part of that change, the function cloning support was adjusted to attempt to enforce this invariant during cloning. However, there were several problems with the implementation. Part of these were fixed in rL304079. However, there was a more fundamental problem with these changes, namely that it bypasses the matadata value map, causing the cloned metadata to be a mix of metadata pointing to the new suprogram (where manual code was added to fix those up) and the old suprogram (where this was not the case). This mismatch could cause a number of different assertion failures in the DWARF emitter. Some of these are given at https://github.com/JuliaLang/julia/issues/22069, but some others have been observed as well. Attempt to rectify this by partially reverting the manual DI metadata fixup, and instead using the standard value map approach. To retain the desired semantics of not duplicating the compilation unit and inlined subprograms, explicitly freeze these in the value map. Reviewers: dblaikie, aprantl, GorNishanov, echristo Reviewed By: aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33655 llvm-svn: 304226
2017-05-27Cloning: Fix debug info cloningGor Nishanov
Summary: I believe https://reviews.llvm.org/rL302576 introduced two bugs: 1) it produces duplicate distinct variables for every: dbg.value describing the same variable. To fix the problme I switched form getDistinct() to get() in DebugLoc.cpp: auto reparentVar = [&](DILocalVariable *Var) { return DILocalVariable::getDistinct( 2) It passes NewFunction plain name as a linkagename parameter to Subprogram constructor. Breaks assert in: || DeclLinkageName.empty()) || LinkageName == DeclLinkageName) && "decl has a linkage name and it is different"' failed. #9 0x00007f5010261b75 llvm::DwarfUnit::applySubprogramDefinitionAttributes(llvm::DISubprogram const*, llvm::DIE&) /home/gor/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:1173:3 # (Edit: reproducer added) Here how https://reviews.llvm.org/rL302576 broke coroutine debug info. Coroutine body of the original function is split into several parts by cloning and removing unneeded code. All parts describe the original function and variables present in the original function. For a simple case, prior to Split, original function has these two blocks: ``` PostSpill: ; preds = %AllocaSpillBB call void @llvm.dbg.value(metadata i32 %x, i64 0, metadata !14, metadata !15), !dbg !13 store i32 %x, i32* %x.addr, align 4 ... and sw.epilog: ; preds = %sw.bb %x.addr.reload.addr = getelementptr inbounds %f.Frame, %f.Frame* %FramePtr, i32 0, i32 4, !dbg !20 %4 = load i32, i32* %x.addr.reload.addr, align 4, !dbg !20 call void @llvm.dbg.value(metadata i32 %4, i64 0, metadata !14, metadata !15), !dbg !13 !14 = !DILocalVariable(name: "x", arg: 1, scope: !6, file: !7, line: 55, type: !11) ``` Note that in two blocks different expression represent the same original user variable X. Before rL302576, for every cloned function there was exactly one cloned DILocalVariable(name: "x" as in: ``` define i8* @f(i32 %x) #0 !dbg !6 { ... !6 = distinct !DISubprogram(name: "f", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, flags: DIFlagPrototyped, ... !14 = !DILocalVariable(name: "x", arg: 1, scope: !6, file: !7, line: 55, type: !11) define internal fastcc void @f.resume(%f.Frame* %FramePtr) #0 !dbg !25 { ... !25 = distinct !DISubprogram(name: "f", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, flags: DIFlagPrototyped, isOptimized: false, unit: !0, variables: !2) !28 = !DILocalVariable(name: "x", arg: 1, scope: !25, file: !7, line: 55, type: !11) ``` After rL302576, for every cloned function there were as many DILocalVariable(name: "x" as there were "call void @llvm.dbg.value" for that variable. This was causing asserts in VerifyDebugInfo and AssemblyPrinter. Example: ``` !27 = distinct !DISubprogram(name: "f", linkageName: "f.resume", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, !29 = distinct !DILocalVariable(name: "x", arg: 1, scope: !27, file: !7, line: 55, type: !11) !39 = distinct !DILocalVariable(name: "x", arg: 1, scope: !27, file: !7, line: 55, type: !11) !41 = distinct !DILocalVariable(name: "x", arg: 1, scope: !27, file: !7, line: 55, type: !11) ``` Second problem: Prior to rL302576, all clones were described by DISubprogram referring to original function. ``` define i8* @f(i32 %x) #0 !dbg !6 { ... !6 = distinct !DISubprogram(name: "f", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, flags: DIFlagPrototyped, define internal fastcc void @f.resume(%f.Frame* %FramePtr) #0 !dbg !25 { ... !25 = distinct !DISubprogram(name: "f", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, flags: DIFlagPrototyped, ``` After rL302576, DISubprogram for clones is of two minds, plain name refers to the original name, linkageName refers to plain name of the clone. ``` !27 = distinct !DISubprogram(name: "f", linkageName: "f.resume", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, ``` I think the assumption in AsmPrinter is that both name and linkageName should refer to the same entity. It asserts here when they are not: ``` || DeclLinkageName.empty()) || LinkageName == DeclLinkageName) && "decl has a linkage name and it is different"' failed. #9 0x00007f5010261b75 llvm::DwarfUnit::applySubprogramDefinitionAttributes(llvm::DISubprogram const*, llvm::DIE&) /home/gor/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:1173:3 ``` After this fix, behavior (with respect to coroutines) reverts to exactly as it was before and therefore making them debuggable again, or even more importantly, compilable, with "-g" Reviewers: dblaikie, echristo, aprantl Reviewed By: dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33614 llvm-svn: 304079
2017-05-09Make it illegal for two Functions to point to the same DISubprogramAdrian Prantl
As recently discussed on llvm-dev [1], this patch makes it illegal for two Functions to point to the same DISubprogram and updates FunctionCloner to also clone the debug info of a function to conform to the new requirement. To simplify the implementation it also factors out the creation of inlineAt locations from the Inliner into a general-purpose utility in DILocation. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-May/112661.html <rdar://problem/31926379> Differential Revision: https://reviews.llvm.org/D32975 This reapplies r302469 with a fix for a bot failure (reparentDebugInfo now checks for the case the orig and new function are identical). llvm-svn: 302576
2017-05-09Revert r302469 "Make it illegal for two Functions to point to the same ↵Hans Wennborg
DISubprogram" This caused PR32977. Original commit message: > Make it illegal for two Functions to point to the same DISubprogram > > As recently discussed on llvm-dev [1], this patch makes it illegal for > two Functions to point to the same DISubprogram and updates > FunctionCloner to also clone the debug info of a function to conform > to the new requirement. To simplify the implementation it also factors > out the creation of inlineAt locations from the Inliner into a > general-purpose utility in DILocation. > > [1] http://lists.llvm.org/pipermail/llvm-dev/2017-May/112661.html > <rdar://problem/31926379> > > Differential Revision: https://reviews.llvm.org/D32975 llvm-svn: 302533
2017-05-08Make it illegal for two Functions to point to the same DISubprogramAdrian Prantl
As recently discussed on llvm-dev [1], this patch makes it illegal for two Functions to point to the same DISubprogram and updates FunctionCloner to also clone the debug info of a function to conform to the new requirement. To simplify the implementation it also factors out the creation of inlineAt locations from the Inliner into a general-purpose utility in DILocation. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-May/112661.html <rdar://problem/31926379> Differential Revision: https://reviews.llvm.org/D32975 llvm-svn: 302469
2017-01-28Cleanup dump() functions.Matthias Braun
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
2016-04-18[NFC] Header cleanupMehdi Amini
Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
2016-01-29Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith ↵Yaron Keren
r259192 post commit comment. clang part in r259232, this is the LLVM part of the patch. llvm-svn: 259240
2015-04-29IR: Give 'DI' prefix to debug info metadataDuncan P. N. Exon Smith
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
2015-04-20DebugInfo: Delete subclasses of DIScopeDuncan P. N. Exon Smith
Delete subclasses of (the already defunct) `DIScope`, updating users to use the raw pointers from the `Metadata` hierarchy directly. llvm-svn: 235356
2015-04-16DebugInfo: Allow DebugLocs to be constructed from constDuncan P. N. Exon Smith
Allow `const`-qualified pointers to be used to construct `DebugLoc`s, as a convenience. llvm-svn: 235115
2015-04-16DebugInfo: Gut DIScope, DIEnumerator and DISubrangeDuncan P. N. Exon Smith
The only class the still has API left is `DIDescriptor` itself. llvm-svn: 235067
2015-04-14DebugInfo: Gut DISubprogram and DILexicalBlock*Duncan P. N. Exon Smith
Gut the `DIDescriptor` wrappers around `MDLocalScope` subclasses. Note that `DILexicalBlock` wraps `MDLexicalBlockBase`, not `MDLexicalBlock`. llvm-svn: 234850
2015-04-06IR: Stop using DIDescriptor::is*() and auto-castingDuncan P. N. Exon Smith
`DIDescriptor`'s subclasses allow construction from incompatible pointers, and `DIDescriptor` defines a series of `isa<>`-like functions (e.g., `isCompileUnit()` instead of `isa<MDCompileUnit>()`) that clients tend to use like this: if (DICompileUnit(N).isCompileUnit()) foo(DICompileUnit(N)); These construction patterns work together to make `DIDescriptor` behave differently from normal pointers. Instead, use built-in `isa<>`, `dyn_cast<>`, etc., and only build `DIDescriptor`s from pointers that are valid for their type. I've split this into a few commits for different parts of LLVM and clang (to decrease the patch size and increase the chance of review). Generally the changes I made were NFC, but in a few places I made things stricter if it made sense from the surrounded code. Eventually a follow-up commit will remove the API for the "old" way. llvm-svn: 234255
2015-03-30DebugLoc: Remove getFromDILexicalBlock()Duncan P. N. Exon Smith
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
2015-03-30DebugInfo: Remove dead code from old DebugLoc APIDuncan P. N. Exon Smith
Remove old API for `DebugLoc` now that all the callers have been updated. If this broke your out-of-tree build, here's a quick map from the old API to the new one: DebugLoc DebugLoc::getFromMDLocation(MDNode *) => DebugLoc::DebugLoc(MDLocation *) => explicit DebugLoc::DebugLoc(MDNode *) // works with broken code MDNode *DebugLoc::getAsMDNode(LLVMContext &) => MDLocation *DebugLoc::get() => DebugLoc::operator MDLocation *() => MDNode *DebugLoc::getAsMDNode() // works with broken code bool DebugLoc::isUnknown() => DebugLoc::operator MDLocation *() i.e.: if (MDLocation *DL = ...) => DebugLoc::operator bool() // works with broken code i.e.: if (DebugLoc DL = ...) void DebugLoc::getScopeAndInlinedAt(MDNode *&, MDNode *&) => use: MDNode *DebugLoc::getScope() and: MDLocation *DebugLoc::getInlinedAt() MDNode *DebugLoc::getScopeNode(LLVMContext &) => MDNode *DebugLoc::getInlinedAtScope() void DebugLoc::dump(LLVMContext &) => void DebugLoc::dump() void DebugLoc::getFnDebugLoc(LLVMContext &) => void DebugLoc::getFnDebugLoc() MDNode *DebugLoc::getScope(LLVMContext &) => MDNode *DebugLoc::getScope() MDNode *DebugLoc::getInlinedAt(LLVMContext &) => MDLocation *DebugLoc::getInlinedAt() I've noted above the only functions that won't crash on broken code (due to downcasting to `MDLocation`). If your code could be dealing with broken IR (i.e., you haven't run the verifier yet, or you've used a temporary node that will eventually (but not yet) get RAUW'ed to an `MDLocation`), you need to restrict yourself to those. llvm-svn: 233599
2015-03-30DebugInfo: Write new DebugLoc APIDuncan P. N. Exon Smith
Rewrite `DebugLoc` with a cleaner API that reflects its current status as a wrapper around an `MDLocation` pointer. - Add accessors/constructors to/from `MDLocation`. - Simplify construction from `MDNode`. - Remove unnecessary `LLVMContext` from APIs. - Drop some API that isn't useful any more. - Rewrite documentation. Actually, I've left the old API behind temporarily at the bottom of the class so that I can update callers in separate commits. I'll remove it once the callers are updated. llvm-svn: 233573
2015-03-30DebugInfo: Implement MDLocation::getInlinedAtScope()Duncan P. N. Exon Smith
Write `MDLocation::getInlinedAtScope()` and use it to re-implement `DebugLoc::getScopeNode()` (and simplify `DISubprogram::Verify()`). This follows the inlined-at linked list and returns the scope of the deepest/last location. llvm-svn: 233568
2015-01-16IR: Cleanup dead code, NFCDuncan P. N. Exon Smith
Line/column fixups already exist in `MDLocation`. Delete the duplicated logic in `DebugLoc`. llvm-svn: 226290
2015-01-14IR: Move MDLocation into placeDuncan P. N. Exon Smith
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
2014-12-09IR: Split Metadata from ValueDuncan P. N. Exon Smith
Split `Metadata` away from the `Value` class hierarchy, as part of PR21532. Assembly and bitcode changes are in the wings, but this is the bulk of the change for the IR C++ API. I have a follow-up patch prepared for `clang`. If this breaks other sub-projects, I apologize in advance :(. Help me compile it on Darwin I'll try to fix it. FWIW, the errors should be easy to fix, so it may be simpler to just fix it yourself. This breaks the build for all metadata-related code that's out-of-tree. Rest assured the transition is mechanical and the compiler should catch almost all of the problems. Here's a quick guide for updating your code: - `Metadata` is the root of a class hierarchy with three main classes: `MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from the `Value` class hierarchy. It is typeless -- i.e., instances do *not* have a `Type`. - `MDNode`'s operands are all `Metadata *` (instead of `Value *`). - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively. If you're referring solely to resolved `MDNode`s -- post graph construction -- just use `MDNode*`. - `MDNode` (and the rest of `Metadata`) have only limited support for `replaceAllUsesWith()`. As long as an `MDNode` is pointing at a forward declaration -- the result of `MDNode::getTemporary()` -- it maintains a side map of its uses and can RAUW itself. Once the forward declarations are fully resolved RAUW support is dropped on the ground. This means that uniquing collisions on changing operands cause nodes to become "distinct". (This already happened fairly commonly, whenever an operand went to null.) If you're constructing complex (non self-reference) `MDNode` cycles, you need to call `MDNode::resolveCycles()` on each node (or on a top-level node that somehow references all of the nodes). Also, don't do that. Metadata cycles (and the RAUW machinery needed to construct them) are expensive. - An `MDNode` can only refer to a `Constant` through a bridge called `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`). As a side effect, accessing an operand of an `MDNode` that is known to be, e.g., `ConstantInt`, takes three steps: first, cast from `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`; third, cast down to `ConstantInt`. The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have metadata schema owners transition away from using `Constant`s when the type isn't important (and they don't care about referring to `GlobalValue`s). In the meantime, I've added transitional API to the `mdconst` namespace that matches semantics with the old code, in order to avoid adding the error-prone three-step equivalent to every call site. If your old code was: MDNode *N = foo(); bar(isa <ConstantInt>(N->getOperand(0))); baz(cast <ConstantInt>(N->getOperand(1))); bak(cast_or_null <ConstantInt>(N->getOperand(2))); bat(dyn_cast <ConstantInt>(N->getOperand(3))); bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4))); you can trivially match its semantics with: MDNode *N = foo(); bar(mdconst::hasa <ConstantInt>(N->getOperand(0))); baz(mdconst::extract <ConstantInt>(N->getOperand(1))); bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2))); bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3))); bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4))); and when you transition your metadata schema to `MDInt`: MDNode *N = foo(); bar(isa <MDInt>(N->getOperand(0))); baz(cast <MDInt>(N->getOperand(1))); bak(cast_or_null <MDInt>(N->getOperand(2))); bat(dyn_cast <MDInt>(N->getOperand(3))); bay(dyn_cast_or_null<MDInt>(N->getOperand(4))); - A `CallInst` -- specifically, intrinsic instructions -- can refer to metadata through a bridge called `MetadataAsValue`. This is a subclass of `Value` where `getType()->isMetadataTy()`. `MetadataAsValue` is the *only* class that can legally refer to a `LocalAsMetadata`, which is a bridged form of non-`Constant` values like `Argument` and `Instruction`. It can also refer to any other `Metadata` subclass. (I'll break all your testcases in a follow-up commit, when I propagate this change to assembly.) llvm-svn: 223802
2014-10-03Revert "Revert "DI: Fold constant arguments into a single MDString""Duncan P. N. Exon Smith
This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
2014-10-02Revert "DI: Fold constant arguments into a single MDString"Duncan P. N. Exon Smith
This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-02DI: Fold constant arguments into a single MDStringDuncan P. N. Exon Smith
This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 218914