aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Bitcode/Writer
AgeCommit message (Collapse)AuthorFilesLines
2022-01-31[ModuleUtils] Move EmbedBufferInModule to LLVMTransformsUtilsFangrui Song1-49/+0
D116542 adds EmbedBufferInModule which introduces a layer violation (https://llvm.org/docs/CodingStandards.html#library-layering). See 2d5f857a1eaf5f7a806d12953c79b96ed8952da8 for detail. EmbedBufferInModule does not use BitcodeWriter functionality and should be moved LLVMTransformsUtils. While here, change the function case to the prevailing convention. It seems that EmbedBufferInModule just follows the steps of EmbedBitcodeInModule. EmbedBitcodeInModule calls WriteBitcodeToFile but has IR update operations which ideally should be refactored to another library. Reviewed By: jhuber6 Differential Revision: https://reviews.llvm.org/D118666
2022-01-31[LLVM] Resolve layer violation in BitcodeWriterJoseph Huber2-2/+33
Summary: The changes introduced in D116542 added a dependency on TransformUtils to use the `appendToCompilerUsed` method. This created a circular dependency. This patch simply copies the needed function locally to remove the dependency.
2022-01-31[OpenMP] Add a flag for embedding a file into the moduleJoseph Huber2-0/+18
This patch adds support for a flag `-fembed-offload-binary` to embed a file as an ELF section in the output by placing it in a global variable. This can be used to bundle offloading files with the host binary so it can be accessed by the linker. The section is named using the `-fembed-offload-section` option. Depends on D116541 Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D116542
2022-01-27[IR] Support ifuncs in opaque pointer modeNikita Popov1-1/+3
Relax the type assertion for opaque pointers, and enumerate the value type in TypeFinder and ValueEnumerator.
2022-01-26[DebugInfo] Add stringLocationExp field to DIStringTypeChih-Ping Chen1-0/+1
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
2022-01-25[NFC] Remove uses of PointerType::getElementType()Nikita Popov1-1/+1
Instead use either Type::getPointerElementType() or Type::getNonOpaquePointerElementType(). This is part of D117885, in preparation for deprecating the API.
2021-12-30[Opaqueptrs][IR Serialization] Improve inlineasm [de]serializationRoman Lebedev1-0/+1
The bitcode reader expected that the pointers are typed, so that it can extract the function type for the assembly so `bitc::CST_CODE_INLINEASM` did not explicitly store said function type. I'm not really sure how the upgrade path will look for existing bitcode, but i think we can easily support opaque pointers going forward, by simply storing the function type. Reviewed By: #opaque-pointers, nikic Differential Revision: https://reviews.llvm.org/D116341
2021-12-20[llvm][IR] Add no_cfi constantSami Tolvanen1-0/+4
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-14[LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.Mingming Liu1-0/+1
Differential Revision: https://reviews.llvm.org/D115492
2021-12-13[llvm] Use llvm::reverse (NFC)Kazu Hirata1-2/+1
2021-12-05[llvm] Use range-based for loops (NFC)Kazu Hirata1-7/+6
2021-12-04[CodeGen] Use range-based for loops (NFC)Kazu Hirata1-2/+1
2021-11-20[llvm] Use range-based for loops (NFC)Kazu Hirata2-17/+15
2021-11-18[llvm] Use range-based for loops (NFC)Kazu Hirata1-3/+2
2021-11-09Revert "[DebugInfo] Enforce implicit constraints on `distinct` MDNodes"Arthur Eubanks1-15/+2
This reverts commit ee7652569854af567ba83e5255d70e80cc8619a1. Causes crashes, see comments in D104827.
2021-11-09[DebugInfo] Enforce implicit constraints on `distinct` MDNodesScott Linder1-2/+15
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-10-08Move TargetRegistry.(h|cpp) from Support to MCReid Kleckner1-1/+1
This moves the registry higher in the LLVM library dependency stack. Every client of the target registry needs to link against MC anyway to actually use the target, so we might as well move this out of Support. This allows us to ensure that Support doesn't have includes from MC/*. Differential Revision: https://reviews.llvm.org/D111454
2021-10-06[IR][NFC] Rename getBaseObject to getAliaseeObjectItay Bookstein1-1/+1
To better reflect the meaning of the now-disambiguated {GlobalValue, GlobalAlias}::getBaseObject after breaking off GlobalIFunc::getResolverFunction (D109792), the function is renamed to getAliaseeObject.
2021-10-06Reland [IR] Increase max alignment to 4GBArthur Eubanks1-1/+5
Currently the max alignment representable is 1GB, see D108661. Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945. This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits. We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now. The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field. Updating clang's max allowed alignment will come in a future patch. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D110451
2021-10-06Revert "Reland [IR] Increase max alignment to 4GB"Arthur Eubanks1-5/+1
This reverts commit 8d64314ffea55f2ad94c1b489586daa8ce30f451.
2021-10-06Reland [IR] Increase max alignment to 4GBArthur Eubanks1-1/+5
Currently the max alignment representable is 1GB, see D108661. Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945. This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits. We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now. The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field. Updating clang's max allowed alignment will come in a future patch. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D110451
2021-10-06Revert "[IR] Increase max alignment to 4GB"Arthur Eubanks1-5/+1
This reverts commit df84c1fe78130a86445d57563dea742e1b85156a. Breaks some bots
2021-10-06[IR] Increase max alignment to 4GBArthur Eubanks1-1/+5
Currently the max alignment representable is 1GB, see D108661. Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945. This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits. We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now. The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field. Updating clang's max allowed alignment will come in a future patch. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D110451
2021-10-05[llvm] Migrate from getNumArgOperands to arg_size (NFC)Kazu Hirata1-6/+3
Note that getNumArgOperands is considered a legacy name. See llvm/include/llvm/IR/InstrTypes.h for details.
2021-10-01[NFC][AttributeList] Replace index_begin/end with an iteratorArthur Eubanks2-2/+2
We expose the fact that we rely on unsigned wrapping to iterate through all indexes. This can be confusing. Rather, keeping it as an implementation detail through an iterator is less confusing and is less code. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D110885
2021-09-27[ThinLTO] Add noRecurse and noUnwind thinlink function attribute propagationmodimo1-0/+3
Thinlink provides an opportunity to propagate function attributes across modules, enabling additional propagation opportunities. This change propagates (currently default off, turn on with `disable-thinlto-funcattrs=1`) noRecurse and noUnwind based off of function summaries of the prevailing functions in bottom-up call-graph order. Testing on clang self-build: 1. There's a 35-40% increase in noUnwind functions due to the additional propagation opportunities. 2. Throughput is measured at 10-15% increase in thinlink time which itself is 1.5% of E2E link time. Implementation-wise this adds the following summary function attributes: 1. noUnwind: function is noUnwind 2. mayThrow: function contains a non-call instruction that `Instruction::mayThrow` returns true on (e.g. windows SEH instructions) 3. hasUnknownCall: function contains calls that don't make it into the summary call-graph thus should not be propagated from (e.g. indirect for now, could add no-opt functions as well) Testing: Clang self-build passes and 2nd stage build passes check-all ninja check-all with newly added tests passing Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D36850
2021-09-24[ThinLTO] Update combined index for SamplePGO indirect calls to localsTeresa Johnson1-27/+1
In ThinLTO for locals we normally compute the GUID from the name after prepending the source path to get a unique global id. SamplePGO indirect call profiles contain the target GUID without this uniquification, however (unless compiling with -funique-internal-linkage-names). In order to correctly handle the call edges added to the combined index for these indirect calls, during importing and bitcode writing we consult a map of original to full GUID to identify the actual callee. However, for a large application this was consuming a lot of compile time as we need to do this repeatedly (especially during importing where we may traverse call edges multiple times). To fix this implement a suggestion in one of the FIXME comments, and actually modify the call edges during a single traversal after the index is built to perform the fixups once. I combined this fixup with the dead code analysis performed on the index in order to avoid adding an additional walk of the index. The dead code analysis is the first analysis performed on the index. This reduced the time required for a large thin link with SamplePGO by about 20%. No new test added, but I confirmed that there are existing tests that will fail when no fixup is performed. Differential Revision: https://reviews.llvm.org/D110374
2021-09-23[ThinLTO] Don't emit original GUID for locals to distributed indexesTeresa Johnson1-1/+8
In ThinLTO for locals we normally compute the GUID from the name after prepending the source path to get a unique global id. SamplePGO indirect call profiles contain the target GUID without this uniquification, however (unless compiling with -funique-internal-linkage-names). Therefore, the index contains the original GUID of the local symbols (without module path prepended to uniquify), in order to correctly handle the call edges added for these indirect call profile targets with SamplePGO. We were emitting these to the combined index when writing it out as bitcode, which is unnecessary and causes overhead when writing out the indexes for distributed backends. The only use of the original GUID name is in the thin link. Suppress it in that case. This reduced the thin link time for a large distributed build by about 7%, and the aggregate size of the serialized indexes by over 2%. Continue to print it when writing out the full index, since that is just used for debugging and testing. Update a distributed thinlto index test to contain a local and ensure that we don't get a COMBINED_ORIGINAL_NAME record. Differential Revision: https://reviews.llvm.org/D110296
2021-09-16[DebugInfo] Enhance DIImportedEntity to accept children entitiesAlok Kumar Sharma1-0/+1
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-07[UseListOrder] Fix use list order for function operandsNikita Popov1-1/+4
Functions can have a personality function, as well as prefix and prologue data as additional operands. Unused operands are assigned a dummy value of i1* null. This patch addresses multiple issues in use-list order preservation for these: * Fix verify-uselistorder to also enumerate the dummy values. This means that now use-list order values of these values are shuffled even if there is no other mention of i1* null in the module. This results in failures of Assembler/call-arg-is-callee.ll, Assembler/opaque-ptr.ll and Bitcode/use-list-order2.ll. * The use-list order prediction in ValueEnumerator does not take into account the fact that a global may use a value more than once and leaves uses in the same global effectively unordered. We should be comparing the operand number here, as we do for the more general case. * While we enumerate all operands of a function together (which seems sensible to me), the bitcode reader would first resolve prefix data for all function, then prologue data for all functions, then personality functions for all functions. Change this to resolve all operands for a given function together instead. Differential Revision: https://reviews.llvm.org/D109282
2021-08-26[DebugInfo] generate btf_tag annotations for func parametersYonghong Song1-0/+1
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-0/+1
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-0/+1
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-0/+2
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-20[clang][Codegen] Introduce the disable_sanitizer_instrumentation attributeAlexander Potapenko1-0/+2
The purpose of __attribute__((disable_sanitizer_instrumentation)) is to prevent all kinds of sanitizer instrumentation applied to a certain function, Objective-C method, or global variable. The no_sanitize(...) attribute drops instrumentation checks, but may still insert code preventing false positive reports. In some cases though (e.g. when building Linux kernel with -fsanitize=kernel-memory or -fsanitize=thread) the users may want to avoid any kind of instrumentation. Differential Revision: https://reviews.llvm.org/D108029
2021-08-19Reland [DebugInfo] generate btf_tag annotations for DIComposite typesYonghong Song1-0/+1
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-1/+0
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-0/+1
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
2021-08-18[Bitcode] Remove unused declaration writeGlobalVariableMetadataAttachment (NFC)Kazu Hirata1-1/+0
The declaration was introduced without a corresponding definition on May 31, 2016 in commit cceae7feda8e33194d1a6c5963bd4114bb8d2b36.
2021-08-17[Bitcode] Remove unused declaration writeBitcodeHeader (NFC)Kazu Hirata1-1/+0
The corresponding definition was removed on Nov 29, 2016 in commit 5a0a2e648c267d99111b21482ca709f580e9ccc2.
2021-07-20[IR] Rename `comdat noduplicates` to `comdat nodeduplicate`Fangrui Song1-1/+1
In the textual format, `noduplicates` means no COMDAT/section group deduplication is performed. Therefore, if both sets of sections are retained, and they happen to define strong external symbols with the same names, there will be a duplicate definition linker error. In PE/COFF, the selection kind lowers to `IMAGE_COMDAT_SELECT_NODUPLICATES`. The name describes the corollary instead of the immediate semantics. The name can cause confusion to other binary formats (ELF, wasm) which have implemented/ want to implement the "no deduplication" selection kind. Rename it to be clearer. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D106319
2021-07-15[IR] Add elementtype attributeNikita Popov1-0/+2
This implements the elementtype attribute specified in D105407. It just adds the attribute and the specified verifier rules, but doesn't yet make use of it anywhere. Differential Revision: https://reviews.llvm.org/D106008
2021-07-02Revert "[DebugInfo] Enforce implicit constraints on `distinct` MDNodes"Jonas Devlieghere1-15/+2
This reverts commit 8cd35ad854ab4458fd509447359066ea3578b494. It breaks `TestMembersAndLocalsWithSameName.py` on GreenDragon and Mikael Holmén points out in D104827 that bitcode files created with the patch cannot be parsed with binaries built before it.
2021-06-29[OpaquePtr][BitcodeWriter] Handle attributes with typesArthur Eubanks1-0/+5
For example, byval. Skip the type attribute auto-upgrade if we already have the type. I've actually seen this error of the ValueEnumerator missing a type attribute's type in a non-opaque pointer context. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D105138
2021-06-28[DebugInfo] Enforce implicit constraints on `distinct` MDNodesScott Linder1-2/+15
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-06-25[OpaquePtr] Enumerate GlobalAlias value typeNikita Popov1-1/+3
The type is no longer implicitly enumerated through the pointer type.
2021-06-25[OpaquePtr] Enumerate alloca typeNikita Popov1-0/+2
This is no longer implicitly enumerated through the pointer type.
2021-06-25[OpaquePtr] Enumerate global variable typeNikita Popov1-1/+3
This is no longer implicitly enumerated through the pointer type.
2021-06-24[OpaquePtr] Introduce option to force all pointers to be opaque pointersArthur Eubanks1-0/+1
We don't want to start updating tests to use opaque pointers until we're close to the opaque pointer transition. However, before the transition we want to run tests as if pointers are opaque pointers to see if there are any crashes. At some point when we have a flag to only create opaque pointers in the bitcode and textual IR readers, and when we have fixed all places that try to read a pointee type, this flag will be useless. However, until then, this can help us find issues more easily. Since the cl::opt is read into LLVMContext, we need to make sure LLVMContext is created after cl::ParseCommandLineOptions(). Previously ValueEnumerator would visit the value types of global values via the pointer type, but with opaque pointers we have to manually visit the value type. Reviewed By: nikic, dexonsmith Differential Revision: https://reviews.llvm.org/D103503
2021-06-23[OpaquePtr] Support call instructionNikita Popov1-1/+3
Add support for call of opaque pointer, currently only possible for indirect calls. This requires a bit of special casing in LLParser, as calls do not specify the callee operand type explicitly. Differential Revision: https://reviews.llvm.org/D104740
generated by cgit v1.1 at 2025-10-03 14:44:13 +0000