aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/IR/LLVMContextImpl.h
AgeCommit message (Collapse)AuthorFilesLines
2023-02-27[LLVMContextImpl] Separate out integer constant zeroesArthur Eubanks1-6/+5
Very small compile time improvement: https://llvm-compile-time-tracker.com/compare.php?from=a628ca4925f7249b4fbd3e932c9627b12e2770dd&to=6a7a8907e8334eaf551742148079c628f78e6ed7&stat=instructions:u Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D144745
2023-01-18[LLVMContext] Remove hasSetOpaquePointersValue() API (NFC)Nikita Popov1-1/+0
Now that we no longer perform any kind of typed pointer guessing, we no longer need this API.
2022-12-20[IR] Add a target extension type to LLVM.Joshua Cranmer1-0/+54
Target-extension types represent types that need to be preserved through optimization, but otherwise are not introspectable by target-independent optimizations. This patch doesn't add any uses of these types by an existing backend, it only provides basic infrastructure such that these types would work correctly. Reviewed By: nikic, barannikov88 Differential Revision: https://reviews.llvm.org/D135202
2022-12-20[llvm] Make llvm::Any similar to std::anySebastian Neubauer1-1/+0
This facilitates replacing llvm::Any with std::any. - Deprecate any_isa in favor of using any_cast(Any*) and checking for nullptr because C++17 has no any_isa. - Remove the assert from any_cast(Any*), so it returns nullptr if the type is not correct. This aligns it with std::any_cast(any*). Use any_cast(Any*) throughout LLVM instead of checks with any_isa. This is the first part outlined in https://discourse.llvm.org/t/rfc-switching-from-llvm-any-to-std-any/67176 Differential Revision: https://reviews.llvm.org/D139973
2022-12-08Revert "[llvm] Replace llvm::Any with std::any"Sebastian Neubauer1-0/+1
msvc fails to link when using any_cast. This seems to be fixed recently only. https://developercommunity.visualstudio.com/t/stdany-doesnt-link-when-exceptions-are-disabled/376072 This reverts commit aeac2e4884a3ce62c920cd51806a9396da64d9f7.
2022-12-08[llvm] Replace llvm::Any with std::anySebastian Neubauer1-1/+0
llvm::Any had several bugs in the past, due to being sensitive to symbol visibility. (See D101972 and D108943) Even with these fixes applied, I still encounter the same issue on Windows. Similar to llvm::Optional going away in favor of std::optional, we can use std::any from C++17. Using std::any fixes the problem and puts the burden to do it correctly on the standard library. Differential Revision: https://reviews.llvm.org/D139532
2022-12-08[DebugInfo] Store optional DIFile::Source as pointerJonas Hahnfeld1-4/+3
getCanonicalMDString() also returns a nullptr for empty strings, which tripped over the getSource() method. Solve the ambiguity of no source versus an optional containing a nullptr by simply storing a pointer. Differential Revision: https://reviews.llvm.org/D138658
2022-12-05[IR] llvm::Optional => std::optionalFangrui Song1-4/+3
Many llvm/IR/* files have been migrated by other contributors. This migrates most remaining files.
2022-12-04IR: HotnessThreshold llvm::Optional => std::optionalFangrui Song1-1/+1
2022-12-04DebugInfoMetadata: convert Optional to std::optionalKrzysztof Parzyszek1-6/+7
2022-11-08Reapply [Assignment Tracking][5/*] Add core infrastructure for instruction ↵OCHyams1-0/+5
reference Previously reverted in 41f5a0004e442ae71c8e754fdadb4bd1e172fb2d. Fold in D133576 previously reverted in d29d5ffb6332569e85d5eda5130603bbd8664635. --- The Assignment Tracking debug-info feature is outlined in this RFC: https://discourse.llvm.org/t/ rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir Overview It's possible to find intrinsics linked to an instruction by looking at the MetadataAsValue uses of the attached DIAssignID. That covers instruction -> intrinsic(s) lookup. Add a global DIAssignID -> instruction(s) map which gives us the ability to perform intrinsic -> instruction(s) lookup. Add plumbing to keep the map up to date through optimisations and add utility functions including two that perform those lookups. Finally, add a unittest. Details In llvm/lib/IR/LLVMContextImpl.h add AssignmentIDToInstrs which maps DIAssignID * attachments to Instruction *s. Because the DIAssignID * is the key we can't use a TrackingMDNodeRef for it, and therefore cannot easily update the mapping when a temporary DIAssignID is replaced. Temporary DIAssignID's are only used in IR parsing to deal with metadata forward references. Update llvm/lib/AsmParser/LLParser.cpp to avoid using temporary DIAssignID's for attachments. In llvm/lib/IR/Metadata.cpp add Instruction::updateDIAssignIDMapping which is called to remove or add an entry (or both) to AssignmentIDToInstrs. Call this from Instruction::setMetadata and add a call to setMetadata in Intruction's dtor that explicitly unsets the DIAssignID so that the mappging gets updated. In llvm/lib/IR/DebugInfo.cpp and DebugInfo.h add utility functions: getAssignmentInsts(const DbgAssignIntrinsic *DAI) getAssignmentMarkers(const Instruction *Inst) RAUW(DIAssignID *Old, DIAssignID *New) deleteAll(Function *F) deleteAssignmentMarkers(const Instruction *Inst) These core utils are tested in llvm/unittests/IR/DebugInfoTest.cpp. Reviewed By: jmorse Differential Revision: https://reviews.llvm.org/D132224
2022-11-07Revert "[Assignment Tracking][5/*] Add core infrastructure for instruction ↵Shubham Sandeep Rastogi1-5/+0
reference" This reverts commit 171f7024cc82e8702abebdedb699d37b50574be7. Reverting this patch because it causes a cyclic dependency in the module build https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/48197/consoleFull#-69937453049ba4694-19c4-4d7e-bec5-911270d8a58c In file included from <module-includes>:1: /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/IR/Argument.h:18:10: fatal error: cyclic dependency in module 'LLVM_IR': LLVM_IR -> LLVM_intrinsic_gen -> LLVM_IR ^ While building module 'LLVM_MC' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/MC/MCAsmInfoCOFF.cpp:14: While building module 'LLVM_IR' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/MC/MCPseudoProbe.h:57: In file included from <module-includes>:12: /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/IR/DebugInfo.h:24:10: fatal error: could not build module 'LLVM_intrinsic_gen' ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~ While building module 'LLVM_MC' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/MC/MCAsmInfoCOFF.cpp:14: In file included from <module-includes>:15: In file included from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/MC/MCContext.h:23: /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/MC/MCPseudoProbe.h:57:10: fatal error: could not build module 'LLVM_IR' ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/MC/MCAsmInfoCOFF.cpp:14:10: fatal error: could not build module 'LLVM_MC' ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~ 4 errors generated.
2022-11-07[Assignment Tracking][5/*] Add core infrastructure for instruction referenceOCHyams1-0/+5
The Assignment Tracking debug-info feature is outlined in this RFC: https://discourse.llvm.org/t/ rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir Overview It's possible to find intrinsics linked to an instruction by looking at the MetadataAsValue uses of the attached DIAssignID. That covers instruction -> intrinsic(s) lookup. Add a global DIAssignID -> instruction(s) map which gives us the ability to perform intrinsic -> instruction(s) lookup. Add plumbing to keep the map up to date through optimisations and add utility functions including two that perform those lookups. Finally, add a unittest. Details In llvm/lib/IR/LLVMContextImpl.h add AssignmentIDToInstrs which maps DIAssignID * attachments to Instruction *s. Because the DIAssignID * is the key we can't use a TrackingMDNodeRef for it, and therefore cannot easily update the mapping when a temporary DIAssignID is replaced. Temporary DIAssignID's are only used in IR parsing to deal with metadata forward references. Update llvm/lib/AsmParser/LLParser.cpp to avoid using temporary DIAssignID's for attachments. In llvm/lib/IR/Metadata.cpp add Instruction::updateDIAssignIDMapping which is called to remove or add an entry (or both) to AssignmentIDToInstrs. Call this from Instruction::setMetadata and add a call to setMetadata in Intruction's dtor that explicitly unsets the DIAssignID so that the mappging gets updated. In llvm/lib/IR/DebugInfo.cpp and DebugInfo.h add utility functions: getAssignmentInsts(const DbgAssignIntrinsic *DAI) getAssignmentMarkers(const Instruction *Inst) RAUW(DIAssignID *Old, DIAssignID *New) deleteAll(Function *F) These core utils are tested in llvm/unittests/IR/DebugInfoTest.cpp. Reviewed By: jmorse Differential Revision: https://reviews.llvm.org/D132224
2022-08-17[clang][llvm][NFC] Change misexpect's tolerance option to be 32-bitPaul Kirth1-2/+2
In D131869 we noticed that we jump through some hoops because we parse the tolerance option used in MisExpect.cpp into a 64-bit integer. This is unnecessary, since the value can only be in the range [0, 100). This patch changes the underlying type to be 32-bit from where it is parsed in Clang through to it's use in LLVM. Reviewed By: jloser Differential Revision: https://reviews.llvm.org/D131935
2022-08-04[IR] Move support for dxil::TypedPointerType to LLVM core IR.Joshua Cranmer1-2/+2
This allows the construct to be shared between different backends. However, it still remains illegal to use TypedPointerType in LLVM IR--the type is intended to remain an auxiliary type, not a real LLVM type. So no support is provided for LLVM-C, nor bitcode, nor LLVM assembly (besides the bare minimum needed to make Type->dump() work properly). Reviewed By: beanz, nikic, aeubanks Differential Revision: https://reviews.llvm.org/D130592
2022-06-18[llvm] Use value_or instead of getValueOr (NFC)Kazu Hirata1-1/+1
2022-06-10Add sanitizer-specific GlobalValue attributes.Mitch Phillips1-0/+3
Plan is the migrate the global variable metadata for sanitizers, that's currently carried around generally in the 'llvm.asan.globals' section, onto the global variable itself. This patch adds the attribute and plumbs it through the LLVM IR and bitcode formats, but is a no-op other than that so far. Reviewed By: vitalybuka, kstoimenov Differential Revision: https://reviews.llvm.org/D126100
2022-04-25Add PointerType analysis for DirectX backendChris Bieneman1-0/+3
As implemented this patch assumes that Typed pointer support remains in the llvm::PointerType class, however this could be modified to use a different subclass of llvm::Type that could be disallowed from use in other contexts. This does not rely on inserting typed pointers into the Module, it just uses the llvm::PointerType class to track and unique types. Fixes #54918 Reviewed By: kuhar Differential Revision: https://reviews.llvm.org/D122268
2022-04-19[msan] Destroy ConstantTokenNone before types aboveVitaly Buka1-2/+2
~ConstantTokenNone access them, so it should be destroyed first.
2022-04-19[misexpect] Re-implement MisExpect DiagnosticsPaul Kirth1-0/+5
Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata. New checks rely on 2 invariants: 1) For frontend instrumentation, MD_prof branch_weights will always be populated before llvm.expect intrinsics are lowered. 2) for IR and sample profiling, llvm.expect intrinsics will always be lowered before branch_weights are populated from the IR profiles. These invariants allow the checking to assume how the existing branch weights are populated depending on the profiling method used, and emit the correct diagnostics. If these invariants are ever invalidated, the MisExpect related checks would need to be updated, potentially by re-introducing MD_misexpect metadata, and ensuring it always will be transformed the same way as branch_weights in other optimization passes. Frontend based profiling is now enabled without using LLVM Args, by introducing a new CodeGen option, and checking if the -Wmisexpect flag has been passed on the command line. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D115907
2022-04-15[DebugInfo] Add a TargetFuncName field in DISubprogram forChih-Ping Chen1-4/+8
specifying DW_AT_trampoline as a string. Also update the signature of DIBuilder::createFunction to reflect this addition. Differential Revision: https://reviews.llvm.org/D123697
2022-03-31Destroy ValueNames after all unique_ptr<Value>Vitaly Buka1-2/+2
This UB detected by -fsanitize-memory-use-after-dtor in tensorflow/MLIR.
2022-03-31Revert "[misexpect] Re-implement MisExpect Diagnostics"Jorge Gorbe Moya1-5/+0
This reverts commit 46774df307159444d65083c2fd82f8574f0ab1d9.
2022-03-31[misexpect] Re-implement MisExpect DiagnosticsPaul Kirth1-0/+5
Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata. New checks rely on 2 invariants: 1) For frontend instrumentation, MD_prof branch_weights will always be populated before llvm.expect intrinsics are lowered. 2) for IR and sample profiling, llvm.expect intrinsics will always be lowered before branch_weights are populated from the IR profiles. These invariants allow the checking to assume how the existing branch weights are populated depending on the profiling method used, and emit the correct diagnostics. If these invariants are ever invalidated, the MisExpect related checks would need to be updated, potentially by re-introducing MD_misexpect metadata, and ensuring it always will be transformed the same way as branch_weights in other optimization passes. Frontend based profiling is now enabled without using LLVM Args, by introducing a new CodeGen option, and checking if the -Wmisexpect flag has been passed on the command line. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D115907
2022-03-29Revert "[misexpect] Re-implement MisExpect Diagnostics"Paul Kirth1-5/+0
This reverts commit 2add3fbd976d7b80a3a7fc14ef0deb9b1ca6beee.
2022-03-28[misexpect] Re-implement MisExpect DiagnosticsPaul Kirth1-0/+5
Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata. New checks rely on 2 invariants: 1) For frontend instrumentation, MD_prof branch_weights will always be populated before llvm.expect intrinsics are lowered. 2) for IR and sample profiling, llvm.expect intrinsics will always be lowered before branch_weights are populated from the IR profiles. These invariants allow the checking to assume how the existing branch weights are populated depending on the profiling method used, and emit the correct diagnostics. If these invariants are ever invalidated, the MisExpect related checks would need to be updated, potentially by re-introducing MD_misexpect metadata, and ensuring it always will be transformed the same way as branch_weights in other optimization passes. Frontend based profiling is now enabled without using LLVM Args, by introducing a new CodeGen option, and checking if the -Wmisexpect flag has been passed on the command line. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D115907
2022-03-21Revert "Revert "[OpaquePtr][LLParser] Automatically detect opaque pointers ↵Arthur Eubanks1-0/+1
in .ll files"" This reverts commit 9c96a6bbfdde665b5c2389100a15acdeea0f4145. Issues were already fixed at head.
2022-03-21Revert "[OpaquePtr][LLParser] Automatically detect opaque pointers in .ll files"Mitch Phillips1-1/+0
This reverts commit 295172ef51c6b9a73bc0fdcfd25f8c41ead9034a. Reason: Broke the ASan buildbot. More details are available on the original Phab review at https://reviews.llvm.org/D119482.
2022-03-18Revert "Revert "Revert "[misexpect] Re-implement MisExpect Diagnostics"""Paul Kirth1-5/+0
This reverts commit 6cf560d69a222bff4af4e1d092437fd77f0f981c.
2022-03-18Revert "Revert "[misexpect] Re-implement MisExpect Diagnostics""Paul Kirth1-0/+5
I mistakenly reverted my commit, so I'm relanding it. This reverts commit 10866a1df4a82cdc54187330c509a2d46235455d.
2022-03-17Revert "[misexpect] Re-implement MisExpect Diagnostics"Paul Kirth1-5/+0
This reverts commit e7749d4713a5ec886011ceb0fc821c6723061724.
2022-03-17[misexpect] Re-implement MisExpect DiagnosticsPaul Kirth1-0/+5
Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata. New checks rely on 2 invariants: 1) For frontend instrumentation, MD_prof branch_weights will always be populated before llvm.expect intrinsics are lowered. 2) for IR and sample profiling, llvm.expect intrinsics will always be lowered before branch_weights are populated from the IR profiles. These invariants allow the checking to assume how the existing branch weights are populated depending on the profiling method used, and emit the correct diagnostics. If these invariants are ever invalidated, the MisExpect related checks would need to be updated, potentially by re-introducing MD_misexpect metadata, and ensuring it always will be transformed the same way as branch_weights in other optimization passes. Frontend based profiling is now enabled without using LLVM Args, by introducing a new CodeGen option, and checking if the -Wmisexpect flag has been passed on the command line. Differential Revision: https://reviews.llvm.org/D115907
2022-03-17[OpaquePtr][LLParser] Automatically detect opaque pointers in .ll filesArthur Eubanks1-0/+1
This allows us to not have to specify -opaque-pointers when updating IR tests from typed pointers to opaque pointers. We detect opaque pointers in .ll files by looking for relevant tokens, either "ptr" or "*". Reviewed By: #opaque-pointers, nikic Differential Revision: https://reviews.llvm.org/D119482
2022-02-02Cleanup header dependencies in LLVMCoreserge-sans-paille1-5/+19
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
2022-01-26[DebugInfo] Add stringLocationExp field to DIStringTypeChih-Ping Chen1-4/+6
DIStringType is used to encode the debug info of a character object in Fortran. A Fortran deferred-length character object is typically implemented as a pair of the following two pieces of info: An address of the raw storage of the characters, and the length of the object. The stringLocationExp field contains the DIExpression to get to the raw storage. This patch also enables the emission of DW_AT_data_location attribute in a DW_TAG_string_type debug info entry based on stringLocationExp in DIStringType. A test is also added to ensure that the bitcode reader is backward compatible with the old DIStringType format. Differential Revision: https://reviews.llvm.org/D117586
2021-12-20[llvm][IR] Add no_cfi constantSami Tolvanen1-0/+2
With Control-Flow Integrity (CFI), the LowerTypeTests pass replaces function references with CFI jump table references, which is a problem for low-level code that needs the address of the actual function body. For example, in the Linux kernel, the code that sets up interrupt handlers needs to take the address of the interrupt handler function instead of the CFI jump table, as the jump table may not even be mapped into memory when an interrupt is triggered. This change adds the no_cfi constant type, which wraps function references in a value that LowerTypeTestsModule::replaceCfiUses does not replace. Link: https://github.com/ClangBuiltLinux/linux/issues/1353 Reviewed By: nickdesaulniers, pcc Differential Revision: https://reviews.llvm.org/D108478
2021-12-03[DebugInfo] Check DIEnumerator bit width when comparing for equalityArthur Eubanks1-2/+3
As mentioned in D106585, this causes non-determinism, which can also be shown by this test case being flaky without this patch. We were using the APSInt's bit width for hashing, but not for checking for equality. APInt::isSameValue() does not check bit width. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D115054
2021-11-11[DebugInfo] run clang-format on some unformatted filesLuís Ferreira1-65/+56
This trivial patch runs clang-format on some unformatted files before doing logic changes and prevent hard to review diffs. Differential Revision: https://reviews.llvm.org/D113572
2021-11-09Revert "[DebugInfo] Enforce implicit constraints on `distinct` MDNodes"Arthur Eubanks1-1/+0
This reverts commit ee7652569854af567ba83e5255d70e80cc8619a1. Causes crashes, see comments in D104827.
2021-11-09[DebugInfo] Enforce implicit constraints on `distinct` MDNodesScott Linder1-0/+1
Add UNIQUED and DISTINCT properties in Metadata.def and use them to implement restrictions on the `distinct` property of MDNodes: * DIExpression can currently be parsed from IR or read from bitcode as `distinct`, but this property is silently dropped when printing to IR. This causes accepted IR to fail to round-trip. As DIExpression appears inline at each use in the canonical form of IR, it cannot actually be `distinct` anyway, as there is no syntax to describe it. * Similarly, DIArgList is conceptually always uniqued. It is currently restricted to only appearing in contexts where there is no syntax for `distinct`, but for consistency it is treated equivalently to DIExpression in this patch. * DICompileUnit is already restricted to always being `distinct`, but along with adding general support for the inverse restriction I went ahead and described this in Metadata.def and updated the parser to be general. Future nodes which have this restriction can share this support. The new UNIQUED property applies to DIExpression and DIArgList, and forbids them to be `distinct`. It also implies they are canonically printed inline at each use, rather than via MDNode ID. The new DISTINCT property applies to DICompileUnit, and requires it to be `distinct`. A potential alternative change is to forbid the non-inline syntax for DIExpression entirely, as is done with DIArgList implicitly by requiring it appear in the context of a function. For example, we would forbid: !named = !{!0} !0 = !DIExpression() Instead we would only accept the equivalent inlined version: !named = !{!DIExpression()} This essentially removes the ability to create a `distinct` DIExpression by construction, as there is no syntax for `distinct` inline. If this patch is accepted as-is, the result would be that the non-canonical version is accepted, but the following would be an error and produce a diagnostic: !named = !{!0} ; error: 'distinct' not allowed for !DIExpression() !0 = distinct !DIExpression() Also update some documentation to consistently use the inline syntax for DIExpression, and to describe the restrictions on `distinct` for nodes where applicable. Reviewed By: StephenTozer, t-tye Differential Revision: https://reviews.llvm.org/D104827
2021-11-04[OpaquePtr] Fix initialization-order-fiascoVitaly Buka1-4/+9
Asan detects it after D112732.
2021-09-16[DebugInfo] Enhance DIImportedEntity to accept children entitiesAlok Kumar Sharma1-5/+8
New field `elements` is added to '!DIImportedEntity', representing list of aliased entities. This is needed to dump optimized debugging information where all names in a module are imported, but a few names are imported with overriding aliases. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D109343
2021-09-10[OpaquePtr] Forbid mixing typed and opaque pointersNikita Popov1-1/+1
Currently, opaque pointers are supported in two forms: The -force-opaque-pointers mode, where all pointers are opaque and typed pointers do not exist. And as a simple ptr type that can coexist with typed pointers. This patch removes support for the mixed mode. You either get typed pointers, or you get opaque pointers, but not both. In the (current) default mode, using ptr is forbidden. In -opaque-pointers mode, all pointers are opaque. The motivation here is that the mixed mode introduces additional issues that don't exist in fully opaque mode. D105155 is an example of a design problem. Looking at D109259, it would probably need additional work to support mixed mode (e.g. to generate GEPs for typed base but opaque result). Mixed mode will also end up inserting many casts between i8* and ptr, which would require significant additional work to consistently avoid. I don't think the mixed mode is particularly valuable, as it doesn't align with our end goal. The only thing I've found it to be moderately useful for is adding some opaque pointer tests in between typed pointer tests, but I think we can live without that. Differential Revision: https://reviews.llvm.org/D109290
2021-08-26[DebugInfo] generate btf_tag annotations for func parametersYonghong Song1-5/+8
Generate btf_tag annotations for function parameters. A field "annotations" is introduced to DILocalVariable, and annotations are represented as an DINodeArray, similar to DIComposite elements. The following example illustrates how annotations are encoded in IR: distinct !DILocalVariable(name: "info",, arg: 1, ..., annotations: !10) !10 = !{!11, !12} !11 = !{!"btf_tag", !"a"} !12 = !{!"btf_tag", !"b"} Differential Revision: https://reviews.llvm.org/D106620
2021-08-26[DebugInfo] generate btf_tag annotations for DIGlobalVariableYonghong Song1-5/+8
Generate btf_tag annotations for DIGlobalVariable. A field "annotations" is introduced to DIGlobalVariable, and annotations are represented as an DINodeArray, similar to DIComposite elements. The following example illustrates how annotations are encoded in IR: distinct !DIGlobalVariable(..., annotations: !10) !10 = !{!11, !12} !11 = !{!"btf_tag", !"a"} !12 = !{!"btf_tag", !"b"} Differential Revision: https://reviews.llvm.org/D106619
2021-08-26[DebugInfo] generate btf_tag annotations for DISubprogram typesYonghong Song1-4/+8
Generate btf_tag annotations for DISubprogram types. A field "annotations" is introduced to DISubprogram, and annotations are represented as an DINodeArray, similar to DIComposite elements. The following example illustrates how annotations are encoded in IR: distinct !DISubprogram(..., annotations: !10) !10 = !{!11, !12} !11 = !{!"btf_tag", !"a"} !12 = !{!"btf_tag", !"b"} Differential Revision: https://reviews.llvm.org/D106618
2021-08-20[DebugInfo] generate btf_tag annotations for DIDerived typesYonghong Song1-5/+6
Generate btf_tag annotations for DIDrived types. More specifically, clang frontend generates the btf_tag annotations for record fields. The annotations are represented as an DINodeArray in DebugInfo. The following example illustrate how annotations are encoded in IR: distinct !DIDerivedType(tag: DW_TAG_member, ..., annotations: !10) !10 = !{!11, !12} !11 = !{!"btf_tag", !"a"} !12 = !{!"btf_tag", !"b"} Differential Revision: https://reviews.llvm.org/D106616
2021-08-19Reland [DebugInfo] generate btf_tag annotations for DIComposite typesYonghong Song1-5/+8
Clang patch D106614 added attribute btf_tag support. This patch generates btf_tag annotations for DIComposite types. A field "annotations" is introduced to DIComposite, and the annotations are represented as an DINodeArray, similar to DIComposite elements. The following example illustrates how annotations are encoded in IR: distinct !DICompositeType(..., annotations: !10) !10 = !{!11, !12} !11 = !{!"btf_tag", !"a"} !12 = !{!"btf_tag", !"b"} Each btf_tag annotation is represented as a 2D array of meta strings. Each record may have more than one btf_tag annotations, as in the above example. Reland with additional fixes for llvm/unittests/IR/DebugTypeODRUniquingTest.cpp. Differential Revision: https://reviews.llvm.org/D106615
2021-08-19Revert "[DebugInfo] generate btf_tag annotations for DIComposite types"Yonghong Song1-8/+5
This reverts commit 2fded193e7a8fb5bd8fb339f00fd9de686390530. Builtbot reports some test failures. Revert now so I can take time to fix the issues.
2021-08-19[DebugInfo] generate btf_tag annotations for DIComposite typesYonghong Song1-5/+8
Clang patch D106614 added attribute btf_tag support. This patch generates btf_tag annotations for DIComposite types. A field "annotations" is introduced to DIComposite, and the annotations are represented as an DINodeArray, similar to DIComposite elements. The following example illustrates how annotations are encoded in IR: distinct !DICompositeType(..., annotations: !10) !10 = !{!11, !12} !11 = !{!"btf_tag", !"a"} !12 = !{!"btf_tag", !"b"} Each btf_tag annotation is represented as a 2D array of meta strings. Each record may have more than one btf_tag annotations, as in the above example. Differential Revision: https://reviews.llvm.org/D106615