summaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CGBlocks.cpp
AgeCommit message (Collapse)Author
2025-06-19[CodeGen] Use range-based for loops (NFC) (#144939)Kazu Hirata
2025-06-02[CodeGen] Move CodeGenPGO behind unique_ptr (NFC) (#142155)Nikita Popov
The InstrProf headers are very expensive. Avoid including them in all of CodeGen/ by moving the CodeGenPGO member behind a unqiue_ptr. This reduces clang build time by 0.8%.
2025-05-16[clang] Use llvm::replace (NFC) (#140264)Kazu Hirata
2025-05-11[clang] Use StringRef::consume_front (NFC) (#139472)Kazu Hirata
2025-04-24[clang] Ensure correct copying of records with authenticated fields (#136783)Oliver Hunt
When records contain fields with pointer authentication, even simple copies can require additional work be performed. This patch contains the core functionality required to handle user defined structs, as well as the implicitly constructed structs for blocks, etc. Co-authored-by: Ahmed Bougacha Co-authored-by: Akira Hatanaka Co-authored-by: John Mccall
2025-02-08[CodeGen] Replace of PointerType::get(Type) with opaque version (NFC) (#124771)Mats Jun Larsen
Follow-up to https://github.com/llvm/llvm-project/issues/123569
2025-02-05CodeGen: support static linking for libclosure (#125384)Saleem Abdulrasool
When building on Windows, dealing with the BlocksRuntime is slightly more complicated. As we are not guaranteed a formward declaration for the blocks runtime ABI symbols, we may generate the declarations for them. In order to properly link against the well-known types, we always annotated them as `__declspec(dllimport)`. This would require the dynamic linking of the blocks runtime under all conditions. However, this is the only the only possible way to us the library. We may be building a fully sealed (static) executable. In such a case, the well known symbols should not be marked as `dllimport` as they are assumed to be statically available with the static linking to the BlocksRuntime. Introduce a new driver/cc1 option `-static-libclosure` which mirrors the myriad of similar options (`-static-libgcc`, `-static-libstdc++`, -static-libsan`, etc).
2024-11-16[CodeGen] Remove unused includes (NFC) (#116459)Kazu Hirata
Identified with misc-include-cleaner.
2024-11-14[clang codegen] Add CreateRuntimeFunction overload that takes a clang type. ↵Eli Friedman
(#113506) Correctly computing the LLVM types/attributes is complicated in general, so add a variant which does that for you.
2024-10-30[clang] Remove some uses of llvm::StructType::setBody. NFC. (#113691)Jay Foad
It is simple to create the struct body up front, now that we have transitioned to opaque pointers.
2024-10-22[clang][OpenCL][CodeGen][AMDGPU] Do not use `private` as the default AS for ↵Alex Voicu
when `generic` is available (#112442) Currently, for AMDGPU, when compiling for OpenCL, we unconditionally use `private` as the default address space. This is wrong for cases where the `generic` address space is available, and is corrected via this patch. In general, this AS map abuse is a bad hack and we should re-work it altogether, but at least after this patch we will stop being incorrect for e.g. OpenCL 2.0.
2024-09-08[Clang] C++20 Coroutines: Introduce Frontend Attribute ↵Yuxuan Chen
[[clang::coro_await_elidable]] (#99282) This patch is the frontend implementation of the coroutine elide improvement project detailed in this discourse post: https://discourse.llvm.org/t/language-extension-for-better-more-deterministic-halo-for-c-coroutines/80044 This patch proposes a C++ struct/class attribute `[[clang::coro_await_elidable]]`. This notion of await elidable task gives developers and library authors a certainty that coroutine heap elision happens in a predictable way. Originally, after we lower a coroutine to LLVM IR, CoroElide is responsible for analysis of whether an elision can happen. Take this as an example: ``` Task foo(); Task bar() { co_await foo(); } ``` For CoroElide to happen, the ramp function of `foo` must be inlined into `bar`. This inlining happens after `foo` has been split but `bar` is usually still a presplit coroutine. If `foo` is indeed a coroutine, the inlined `coro.id` intrinsics of `foo` is visible within `bar`. CoroElide then runs an analysis to figure out whether the SSA value of `coro.begin()` of `foo` gets destroyed before `bar` terminates. `Task` types are rarely simple enough for the destroy logic of the task to reference the SSA value from `coro.begin()` directly. Hence, the pass is very ineffective for even the most trivial C++ Task types. Improving CoroElide by implementing more powerful analyses is possible, however it doesn't give us the predictability when we expect elision to happen. The approach we want to take with this language extension generally originates from the philosophy that library implementations of `Task` types has the control over the structured concurrency guarantees we demand for elision to happen. That is, the lifetime for the callee's frame is shorter to that of the caller. The ``[[clang::coro_await_elidable]]`` is a class attribute which can be applied to a coroutine return type. When a coroutine function that returns such a type calls another coroutine function, the compiler performs heap allocation elision when the following conditions are all met: - callee coroutine function returns a type that is annotated with ``[[clang::coro_await_elidable]]``. - In caller coroutine, the return value of the callee is a prvalue that is immediately `co_await`ed. From the C++ perspective, it makes sense because we can ensure the lifetime of elided callee cannot exceed that of the caller if we can guarantee that the caller coroutine is never destroyed earlier than the callee coroutine. This is not generally true for any C++ programs. However, the library that implements `Task` types and executors may provide this guarantee to the compiler, providing the user with certainty that HALO will work on their programs. After this patch, when compiling coroutines that return a type with such attribute, the frontend checks that the type of the operand of `co_await` expressions (not `operator co_await`). If it's also attributed with `[[clang::coro_await_elidable]]`, the FE emits metadata on the call or invoke instruction as a hint for a later middle end pass to elide the elision. The original patch version is https://github.com/llvm/llvm-project/pull/94693 and as suggested, the patch is split into frontend and middle end solutions into stacked PRs. The middle end CoroSplit patch can be found at https://github.com/llvm/llvm-project/pull/99283 The middle end transformation that performs the elide can be found at https://github.com/llvm/llvm-project/pull/99285
2024-07-09[CodeGen] Add a flag to disable emitting block signature strings (#96944)Akira Hatanaka
Users who don't need the signature string to be emitted can use the flag to reduce code size. rdar://121933818
2024-06-24Revert "[IR][NFC] Update IRBuilder to use InsertPosition (#96497)"Stephen Tozer
Reverts the above commit, as it updates a common header function and did not update all callsites: https://lab.llvm.org/buildbot/#/builders/29/builds/382 This reverts commit 6481dc57612671ebe77fe9c34214fba94e1b3b27.
2024-06-24[IR][NFC] Update IRBuilder to use InsertPosition (#96497)Stephen Tozer
Uses the new InsertPosition class (added in #94226) to simplify some of the IRBuilder interface, and removes the need to pass a BasicBlock alongside a BasicBlock::iterator, using the fact that we can now get the parent basic block from the iterator even if it points to the sentinel. This patch removes the BasicBlock argument from each constructor or call to setInsertPoint. This has no functional effect, but later on as we look to remove the `Instruction *InsertBefore` argument from instruction-creation (discussed [here](https://discourse.llvm.org/t/psa-instruction-constructors-changing-to-iterator-only-insertion/77845)), this will simplify the process by allowing us to deprecate the InsertPosition constructor directly and catch all the cases where we use instructions rather than iterators.
2024-06-11[clang] Replace X && isa<Y>(X) with isa_and_nonnull<Y>(X). NFC (#94987)Pavel Samolysov
This addresses a clang-tidy suggestion.
2024-05-20[clang][CodeGen] Remove unused LValue::getAddress CGF arg. (#92465)Ahmed Bougacha
This is in effect a revert of f139ae3d93797, as we have since gained a more sophisticated way of doing extra IRGen with the addition of RawAddress in #86923.
2024-04-11[NFC][Clang] Improve const correctness for IdentifierInfo (#79365)Bill Wendling
The IdentifierInfo isn't typically modified. Use 'const' wherever possible.
2024-04-04[clang][CGBlocks] Remove unused variable "refType" [NFC]Mikael Holmen
Without the change gcc warned like ../../clang/lib/CodeGen/CGBlocks.cpp:965:21: warning: unused variable 'refType' [-Wunused-variable] 965 | } else if (auto refType = type->getAs<ReferenceType>()) { | ^~~~~~~
2024-03-28[CodeGen][arm64e] Add methods and data members to Address, which are needed ↵Akira Hatanaka
to authenticate signed pointers (#86923) To authenticate pointers, CodeGen needs access to the key and discriminators that were used to sign the pointer. That information is sometimes known from the context, but not always, which is why `Address` needs to hold that information. This patch adds methods and data members to `Address`, which will be needed in subsequent patches to authenticate signed pointers, and uses the newly added methods throughout CodeGen. Although this patch isn't strictly NFC as it causes CodeGen to use different code paths in some cases (e.g., `mergeAddressesInConditionalExpr`), it doesn't cause any changes in functionality as it doesn't add any information needed for authentication. In addition to the changes mentioned above, this patch introduces class `RawAddress`, which contains a pointer that we know is unsigned, and adds several new functions for creating `Address` and `LValue` objects. This reapplies d9a685a9dd589486e882b722e513ee7b8c84870c, which was reverted because it broke ubsan bots. There seems to be a bug in coroutine code-gen, which is causing EmitTypeCheck to use the wrong alignment. For now, pass alignment zero to EmitTypeCheck so that it can compute the correct alignment based on the passed type (see function EmitCXXMemberOrOperatorMemberCallExpr).
2024-03-27Revert "[CodeGen][arm64e] Add methods and data members to Address, which are ↵Akira Hatanaka
needed to authenticate signed pointers (#86721)" (#86898) This reverts commit d9a685a9dd589486e882b722e513ee7b8c84870c. The commit broke ubsan bots.
2024-03-27[CodeGen][arm64e] Add methods and data members to Address, which are needed ↵Akira Hatanaka
to authenticate signed pointers (#86721) To authenticate pointers, CodeGen needs access to the key and discriminators that were used to sign the pointer. That information is sometimes known from the context, but not always, which is why `Address` needs to hold that information. This patch adds methods and data members to `Address`, which will be needed in subsequent patches to authenticate signed pointers, and uses the newly added methods throughout CodeGen. Although this patch isn't strictly NFC as it causes CodeGen to use different code paths in some cases (e.g., `mergeAddressesInConditionalExpr`), it doesn't cause any changes in functionality as it doesn't add any information needed for authentication. In addition to the changes mentioned above, this patch introduces class `RawAddress`, which contains a pointer that we know is unsigned, and adds several new functions for creating `Address` and `LValue` objects. This reapplies 8bd1f9116aab879183f34707e6d21c7051d083b6. The commit broke msan bots because LValue::IsKnownNonNull was uninitialized.
2024-03-26Revert "[CodeGen][arm64e] Add methods and data members to Address, which are ↵Akira Hatanaka
needed to authenticate signed pointers (#67454)" (#86674) This reverts commit 8bd1f9116aab879183f34707e6d21c7051d083b6. It appears that the commit broke msan bots.
2024-03-25[CodeGen][arm64e] Add methods and data members to Address, which are needed ↵Akira Hatanaka
to authenticate signed pointers (#67454) To authenticate pointers, CodeGen needs access to the key and discriminators that were used to sign the pointer. That information is sometimes known from the context, but not always, which is why `Address` needs to hold that information. This patch adds methods and data members to `Address`, which will be needed in subsequent patches to authenticate signed pointers, and uses the newly added methods throughout CodeGen. Although this patch isn't strictly NFC as it causes CodeGen to use different code paths in some cases (e.g., `mergeAddressesInConditionalExpr`), it doesn't cause any changes in functionality as it doesn't add any information needed for authentication. In addition to the changes mentioned above, this patch introduces class `RawAddress`, which contains a pointer that we know is unsigned, and adds several new functions for creating `Address` and `LValue` objects.
2024-03-18[RemoveDIs] Update Clang front end to handle DbgRecords (#84756)Orlando Cazalet-Hyams
This patch fixes problems that pop up when clang emits DbgRecords instead of debug intrinsics. Note: this doesn't mean clang is emitting DbgRecords yet, because the modules it creates are still always in the old debug mode. That will come in a future patch. Depends on #84739
2024-03-18Revert "[RemoveDIs] Update Clang front end to handle DbgRecords (#84756)"Orlando Cazalet-Hyams
This reverts commit 6f60ad7e9a3508f19d54c827cf11f7930a0685ee. Buildbots: https://lab.llvm.org/buildbot/#/builders/196/builds/47206
2024-03-18Revert "Fix formatting in #84756"Orlando Cazalet-Hyams
This reverts commit b097b3dc2ba2517621a5e3da3237a77ed0e7586f. Buildbots: https://lab.llvm.org/buildbot/#/builders/196/builds/47206
2024-03-18Fix formatting in #84756Orlando Cazalet-Hyams
2024-03-18[RemoveDIs] Update Clang front end to handle DbgRecords (#84756)Orlando Cazalet-Hyams
This patch fixes problems that pop up when clang emits DbgRecords instead of debug intrinsics. Note: this doesn't mean clang is emitting DbgRecords yet, because the modules it creates are still always in the old debug mode. That will come in a future patch. Depends on #84739
2023-11-06[clang][NFC] Refactor `ImplicitParamDecl::ImplicitParamKind`Vlad Serebrennikov
This patch converts `ImplicitParamDecl::ImplicitParamKind` into a scoped enum at namespace scope, making it eligible for forward declaring. This is useful for `preferred_type` annotations on bit-fields.
2023-11-02[clang] Remove no-op ptr-to-ptr bitcasts (NFC)Youngsuk Kim
Opaque ptr cleanup effort (NFC)
2023-11-01[CGBlocks] Remove no-op ptr-to-ptr bitcasts (NFC)Youngsuk Kim
Opaque ptr cleanup effort. NFC.
2023-10-02-fsanitize=function: fix MSVC hashing to sugared type (#66816)Matheus Izvekov
Hashing the sugared type instead of the canonical type meant that a simple example like this would always fail under MSVC: ``` static auto l() {} int main() { auto a = l; a(); } ``` `clang --target=x86_64-pc-windows-msvc -fno-exceptions -fsanitize=function -g -O0 -fuse-ld=lld -o test.exe test.cc` produces: ``` test.cc:4:3: runtime error: call to function l through pointer to incorrect function type 'void (*)()' ```
2023-09-25[clang][CodeGen] Simplify code based on opaque pointers (#65624)Björn Pettersson
- Update CodeGenTypeCache to use a single union for all pointers in address space zero. - Introduce a UnqualPtrTy in CodeGenTypeCache, and use that (for example instead of llvm::PointerType::getUnqual) in some places. - Drop some redundant bit/pointers casts from ptr to ptr.
2023-08-10[clang] Drop some references to typed pointers (getInt8PtrTy). NFCBjorn Pettersson
Differential Revision: https://reviews.llvm.org/D157550
2023-08-03[clang][CodeGen] Drop some typed pointer bitcastsBjorn Pettersson
Differential Revision: https://reviews.llvm.org/D156911
2023-07-30[CodeGen] Remove unused declaration/function BlockCaptureManagedEntityKazu Hirata
The last use was removed by: commit e5df9cc098b554ebb066792e40cbde6feddc57bc Author: Akira Hatanaka <ahatanaka@apple.com> Date: Sat Jan 8 13:27:28 2022 -0800
2023-06-18[clang] Replace uses of CGBuilderTy::CreateElementBitCast (NFC)Youngsuk Kim
* Add `Address::withElementType()` as a replacement for `CGBuilderTy::CreateElementBitCast`. * Partial progress towards replacing `CreateElementBitCast`, as it no longer does what its name suggests. Either replace its uses with `Address::withElementType()`, or remove them if no longer needed. * Remove unused parameter 'Name' of `CreateElementBitCast` Reviewed By: barannikov88, nikic Differential Revision: https://reviews.llvm.org/D153196
2023-06-16[clang] Replace use of Type::getPointerTo() (NFC)Youngsuk Kim
Partial progress towards replacing in-tree uses of `Type::getPointerTo()`. This needs to be done before deprecating the API. Reviewed By: nikic, barannikov88 Differential Revision: https://reviews.llvm.org/D152321
2023-01-13[clang][NFC] Remove dependency on DataLayout::getPrefTypeAlignmentGuillaume Chatelet
2022-11-30[clang][TargetInfo] Use LangAS for getPointer{Width,Align}()Alex Richardson
Mixing LLVM and Clang address spaces can result in subtle bugs, and there is no need for this hook to use the LLVM IR level address spaces. Most of this change is just replacing zero with LangAS::Default, but it also allows us to remove a few calls to getTargetAddressSpace(). This also removes a stale comment+workaround in CGDebugInfo::CreatePointerLikeType(): ASTContext::getTypeSize() does return the expected size for ReferenceType (and handles address spaces). Differential Revision: https://reviews.llvm.org/D138295
2022-09-03[clang] Qualify auto in range-based for loops (NFC)Kazu Hirata
2022-03-23[CGBlocks] Don't assume presence of bitcastNikita Popov
With opaque pointers, the bitcast constexpr will not be present.
2022-03-18Use llvm::append_range instead of push_back loops where applicable. NFCI.Benjamin Kramer
2022-03-17[CodeGen] Avoid pointer element type access for blocksNikita Popov
Pass the block struct type down to the TargetInfo hooks.
2022-03-03[NFC][Clang][OpaquePtr] Remove calls to Address::deprecated inAkira Hatanaka
CGBlocks.cpp Differential Revision: https://reviews.llvm.org/D120856
2022-02-17[CodeGen] Rename deprecated Address constructorNikita Popov
To make uses of the deprecated constructor easier to spot, and to ensure that no new uses are introduced, rename it to Address::deprecated(). While doing the rename, I've filled in element types in cases where it was relatively obvious, but we're still left with 135 calls to the deprecated constructor.
2022-02-14[CGBuilder] Remove CreateBitCast() methodNikita Popov
Use CreateElementBitCast() instead, or don't work on Address where not necessary.
2022-01-11[CodeGen] Treat ObjC `__unsafe_unretained` and class types as trivialAkira Hatanaka
when generating copy/dispose helper functions Analyze the block captures just once before generating copy/dispose block helper functions and honor the inert `__unsafe_unretained` qualifier. This refactor fixes a bug where captures of ObjC `__unsafe_unretained` and class types were needlessly retained/released by the copy/dispose helper functions. Differential Revision: https://reviews.llvm.org/D116948
2021-12-15[CodeGen] Avoid some pointer element type accessesNikita Popov