aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CodeGenFunction.h
AgeCommit message (Collapse)AuthorFilesLines
24 hours[Clang][OpenMP][LoopTransformations] Implement "#pragma omp fuse" loop ↵Walter J.T.V1-0/+1
transformation directive and "looprange" clause (#139293) This change implements the fuse directive, `#pragma omp fuse`, as specified in the OpenMP 6.0, along with the `looprange` clause in clang. This change also adds minimal stubs so flang keeps compiling (a full implementation in flang of this directive is still pending). --------- Co-authored-by: Roger Ferrer Ibanez <roger.ferrer@bsc.es>
2025-09-09[clang][OpenMP][SPIR-V] Fix addrspace of pointer kernel arguments (#157172)Nick Sarnie1-2/+3
In SPIR-V, kernel arguments are not allowed to be in the Generic AS, in both Intel's internal SPIR-V offloading implementation as well as HIPSPV, `CrossWorkgroup` AS1 is used. Do the same for OMPSPV. Currently with Generic AS the `llvm-spirv` translator blows up if we are using it, and if not, the GPU runtime blows up. To get the existing logic to set the correct AS to kick in, we need to know if the function is a kernel or not at the time we first create the function that may end up as the kernel. I use the existing `arrangeSYCLKernelCallerDeclaration` function to do the right kernel ABI computation, but since the function is not specific to SYCL anymore because I merged all the device kernel clang attributes into one. Rename the function to be accurate to the current behavior, `arrangeDeviceKernelCallerDeclaration`. --------- Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
2025-09-02[Clang] [C2y] Implement N3355 ‘Named Loops’ (#152870)Sirraide1-2/+6
This implements support for [named loops](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm) for C2y. When parsing a `LabelStmt`, we create the `LabeDecl` early before we parse the substatement; this label is then passed down to `ParseWhileStatement()` and friends, which then store it in the loop’s (or switch statement’s) `Scope`; when we encounter a `break/continue` statement, we perform a lookup for the label (and error if it doesn’t exist), and then walk the scope stack and check if there is a scope whose preceding label is the target label, which identifies the jump target. The feature is only supported in C2y mode, though a cc1-only option exists for testing (`-fnamed-loops`), which is mostly intended to try and make sure that we don’t have to refactor this entire implementation when/if we start supporting it in C++. --------- Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
2025-08-27[UBSan][BoundsSafety] Implement support for more expressive "trap reasons" ↵Dan Liew1-2/+3
(#154618) In 29992cfd628ed5b968ccb73b17ed0521382ba317 (#145967) support was added for "trap reasons" on traps emitted in UBSan in trapping mode (e.g. `-fsanitize-trap=undefined`). This improved the debugging experience by attaching the reason for trapping as a string on the debug info on trap instructions. Consumers such as LLDB can display this trap reason string when the trap is reached. A limitation of that patch is that the trap reason string is hard-coded for each `SanitizerKind` even though the compiler actually has much more information about the trap available at compile time that could be shown to the user. This patch is an incremental step in fixing that. It consists of two main steps. **1. Introduce infrastructure for building trap reason strings** To make it convenient to construct trap reason strings this patch re-uses Clang's powerful diagnostic infrastructure to provide a convenient API for constructing trap reason strings. This is achieved by: * Introducing a new `Trap` diagnostic kind to represent trap diagnostics in TableGen files. * Adding a new `Trap` diagnostic component. While this part probably isn't technically necessary it seemed like I should follow the existing convention used by the diagnostic system. * Adding `DiagnosticTrapKinds.td` to describe the different trap reasons. * Add the `TrapReasonBuilder` and `TrapReason` classes to provide an interface for constructing trap reason strings and the trap category. Note this API while similar to `DiagnosticBuilder` has different semantics which are described in the code comments. In particular the behavior when the destructor is called is very different. * Adding `CodeGenModule::BuildTrapReason()` as a convenient constructor for the `TrapReasonBuilder`. This use of the diagnostic system is a little unusual in that the emitted trap diagnostics aren't actually consumed by normal diagnostic consumers (e.g. the console). Instead the `TrapReasonBuilder` is just used to format a string, so in effect the builder is somewhat analagous to "printf". However, re-using the diagnostics system in this way brings a several benefits: * The powerful diagnostic templating languge (e.g. `%select`) can be used. * Formatting Clang data types (e.g. `Type`, `Expr`, etc.) just work out-of-the-box. * Describing trap reasons in tablegen files opens the door for translation to different languages in the future. * The `TrapReasonBuilder` API is very similar to `DiagnosticBuilder` which makes it easy to use by anyone already familiar with Clang's diagnostic system. While UBSan is the first consumer of this new infrastructure the intent is to use this to overhaul how trap reasons are implemented in the `-fbounds-safety` implementation (currently exists downstream). **2. Apply the new infrastructure to UBSan checks for arithmetic overflow** To demonstrate using `TrapReasonBuilder` this patch applies it to UBSan traps for arithmetic overflow. The intention is that we would iteratively switch to using the `TrapReasonBuilder` for all UBSan traps where it makes sense in future patches. Previously for code like ``` int test(int a, int b) { return a + b; } ``` The trap reason string looked like ``` Undefined Behavior Sanitizer: Integer addition overflowed ``` now the trap message looks like: ``` Undefined Behavior Sanitizer: signed integer addition overflow in 'a + b' ``` This string is much more specific because * It explains if signed or unsigned overflow occurred * It actually shows the expression that overflowed One possible downside of this approach is it may blow up Debug info size because now there can be many more distinct trap reason strings. To allow users to avoid this a new driver/cc1 flag `-fsanitize-debug-trap-reasons=` has been added which can either be `none` (disable trap reasons entirely), `basic` (use the per `SanitizerKind` hard coded strings), and `detailed` (use the new expressive trap reasons implemented in this patch). The default is `detailed` to give the best out-of-the-box debugging experience. The existing `-fsanitize-debug-trap-reasons` and `-fno-sanitize-debug-trap-reasons` have been kept for compatibility and are aliases of the new flag with `detailed` and `none` arguments passed respectively. rdar://158612755
2025-08-27[clang] NFC: reintroduce clang/include/clang/AST/Type.h (#155050)Matheus Izvekov1-1/+1
This reintroduces `Type.h`, having earlier been renamed to `TypeBase.h`, as a redirection to `TypeBase.h`, and redirects most users to include the former instead. This is a preparatory patch for being able to provide inline definitions for `Type` methods which would otherwise cause a circular dependency with `Decl{,CXX}.h`. Doing these operations into their own NFC patch helps the git rename detection logic work, preserving the history. This patch makes clang just a little slower to build (~0.17%), just because it makes more code indirectly include `DeclCXX.h`.
2025-08-27[clang] NFC: rename clang/include/clang/AST/Type.h to TypeBase.h (#155049)Matheus Izvekov1-1/+1
This is a preparatory patch, to be able to provide inline definitions for `Type` functions which depend on `Decl{,CXX}.h`. As the latter also depends on `Type.h`, this would not be possible without some reorganizing. Splitting this rename into its own patch allows git to track this as a rename, and preserve all git history, and not force any code reformatting. A later NFC patch will reintroduce `Type.h` as redirection to `TypeBase.h`, rewriting most places back to directly including `Type.h` instead of `TypeBase.h`, leaving only a handful of places where this is necessary. Then yet a later patch will exploit this by making more stuff inline.
2025-08-25[clang] NFC: change more places to use Type::getAsTagDecl and friends (#155313)Matheus Izvekov1-3/+1
This changes a bunch of places which use getAs<TagType>, including derived types, just to obtain the tag definition. This is preparation for #155028, offloading all the changes that PR used to introduce which don't depend on any new helpers.
2025-08-21[clang][CodeGen] cast addr space of ReturnValue if needed (#154380)macurtis-amd1-0/+7
Fixes a bug on AMDGPU targets where a pointer was stored as address space 5, but then loaded as address space 0. Issue found as part of [Kokkos](https://github.com/kokkos/kokkos) testing, specifically `hip.atomics` (see [core/unit_test/TestAtomics.hpp](https://github.com/kokkos/kokkos/blob/develop/core/unit_test/TestAtomics.hpp)). Issue was introduced by commit [39ec9de7c230](https://github.com/llvm/llvm-project/commit/39ec9de7c230) - [clang][CodeGen] sret args should always point to the alloca AS, so use that (https://github.com/llvm/llvm-project/pull/114062).
2025-08-13[WIP] [clang] Align cleanup structs to prevent SIGBUS on sparc32 (#152866)Koakuma1-2/+3
The cleanup structs expect that pointers and (u)int64_t have the same alignment requirements, which isn't true on sparc32, which causes SIGBUSes. See also: https://github.com/llvm/llvm-project/issues/66620
2025-08-09[clang] Improve nested name specifier AST representation (#147835)Matheus Izvekov1-3/+3
This is a major change on how we represent nested name qualifications in the AST. * The nested name specifier itself and how it's stored is changed. The prefixes for types are handled within the type hierarchy, which makes canonicalization for them super cheap, no memory allocation required. Also translating a type into nested name specifier form becomes a no-op. An identifier is stored as a DependentNameType. The nested name specifier gains a lightweight handle class, to be used instead of passing around pointers, which is similar to what is implemented for TemplateName. There is still one free bit available, and this handle can be used within a PointerUnion and PointerIntPair, which should keep bit-packing aficionados happy. * The ElaboratedType node is removed, all type nodes in which it could previously apply to can now store the elaborated keyword and name qualifier, tail allocating when present. * TagTypes can now point to the exact declaration found when producing these, as opposed to the previous situation of there only existing one TagType per entity. This increases the amount of type sugar retained, and can have several applications, for example in tracking module ownership, and other tools which care about source file origins, such as IWYU. These TagTypes are lazily allocated, in order to limit the increase in AST size. This patch offers a great performance benefit. It greatly improves compilation time for [stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for `test_on2.cpp` in that project, which is the slowest compiling test, this patch improves `-c` compilation time by about 7.2%, with the `-fsyntax-only` improvement being at ~12%. This has great results on compile-time-tracker as well: ![image](https://github.com/user-attachments/assets/700dce98-2cab-4aa8-97d1-b038c0bee831) This patch also further enables other optimziations in the future, and will reduce the performance impact of template specialization resugaring when that lands. It has some other miscelaneous drive-by fixes. About the review: Yes the patch is huge, sorry about that. Part of the reason is that I started by the nested name specifier part, before the ElaboratedType part, but that had a huge performance downside, as ElaboratedType is a big performance hog. I didn't have the steam to go back and change the patch after the fact. There is also a lot of internal API changes, and it made sense to remove ElaboratedType in one go, versus removing it from one type at a time, as that would present much more churn to the users. Also, the nested name specifier having a different API avoids missing changes related to how prefixes work now, which could make existing code compile but not work. How to review: The important changes are all in `clang/include/clang/AST` and `clang/lib/AST`, with also important changes in `clang/lib/Sema/TreeTransform.h`. The rest and bulk of the changes are mostly consequences of the changes in API. PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just for easier to rebasing. I plan to rename it back after this lands. Fixes #136624 Fixes https://github.com/llvm/llvm-project/issues/43179 Fixes https://github.com/llvm/llvm-project/issues/68670 Fixes https://github.com/llvm/llvm-project/issues/92757
2025-08-08[Clang][CodeGen] Move `EmitPointerArithmetic` into `CodeGenFunction`. NFC. ↵Yingwei Zheng1-0/+6
(#152634) `CodeGenFunction::EmitPointerArithmetic` is needed by https://github.com/llvm/llvm-project/pull/152575. Separate the NFC changes into a new PR for smooth review.
2025-08-08[IR] Remove size argument from lifetime intrinsics (#150248)Nikita Popov1-16/+8
Now that #149310 has restricted lifetime intrinsics to only work on allocas, we can also drop the explicit size argument. Instead, the size is implied by the alloca. This removes the ability to only mark a prefix of an alloca alive/dead. We never used that capability, so we should remove the need to handle that possibility everywhere (though many key places, including stack coloring, did not actually respect this).
2025-06-25Delete copy constructor/assignment; NFC (#145689)Aaron Ballman1-0/+3
This is an RAII object and static analysis was flagging it for not following the rule of three (or five).
2025-06-19[HLSL][SPIRV] Reapply "[HLSL][SPIRV] Add vk::constant_id attribute." (#144902)Steven Perron1-0/+6
- **Reapply "[HLSL][SPIRV] Add vk::constant_id attribute." (#144812)** - **Fix memory leak.**
2025-06-18Revert "[HLSL][SPIRV] Add vk::constant_id attribute." (#144812)Steven Perron1-6/+0
Reverts llvm/llvm-project#143544
2025-06-18[HLSL][SPIRV] Add vk::constant_id attribute. (#143544)Steven Perron1-0/+6
The vk::constant_id attribute is used to indicate that a global const variable represents a specialization constant in SPIR-V. This PR adds this attribute to clang. The documentation for the attribute is [here](https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/SPIR-V.rst#specialization-constants). The strategy is to to modify the initializer to get the value of a specialize constant for a builtin defined in the SPIR-V backend. Implements https://github.com/llvm/wg-hlsl/pull/287 Fixes https://github.com/llvm/llvm-project/issues/142448 --------- Co-authored-by: Nathan Gauër <github@keenuts.net>
2025-06-06[ubsan] Add more -fsanitize-annotate-debug-info checks (#141997)Thurston Dang1-3/+5
This extends https://github.com/llvm/llvm-project/pull/138577 to more UBSan checks, by changing SanitizerDebugLocation (formerly SanitizerScope) to add annotations if enabled for the specified ordinals. Annotations will use the ordinal name if there is exactly one ordinal specified in the SanitizerDebugLocation; otherwise, it will use the handler name. Updates the tests from https://github.com/llvm/llvm-project/pull/141814. --------- Co-authored-by: Vitaly Buka <vitalybuka@google.com>
2025-06-04[KeyInstr][Clang] Ret atom (#134652)Orlando Cazalet-Hyams1-2/+5
This patch is part of a stack that teaches Clang to generate Key Instructions metadata for C and C++. When returning a value, stores to the `retval` allocas and branches to `return` block are put in the same atom group. They are both rank 1, which could in theory introduce an extra step in some optimized code. This low risk currently feels an acceptable for keeping the code a bit simpler (as opposed to adding scaffolding to make the store rank 2). In the case of a single return (no control flow) the return instruction inherits the atom group of the branch to the return block when the blocks get folded togather. RFC: https://discourse.llvm.org/t/rfc-improving-is-stmt-placement-for-better-interactive-debugging/82668 The feature is only functional in LLVM if LLVM is built with CMake flag LLVM_EXPERIMENTAL_KEY_INSTRUCTIONs. Eventually that flag will be removed.
2025-06-02[NFC][CodeGen] Extract SanitizerHandler into own header (#142527)Vitaly Buka1-34/+1
2025-06-02[CodeGen] Move CodeGenPGO behind unique_ptr (NFC) (#142155)Nikita Popov1-40/+12
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-23[KeyInstr][Clang] If stmt atom (#134642)Orlando Cazalet-Hyams1-0/+5
This patch is part of a stack that teaches Clang to generate Key Instructions metadata for C and C++. RFC: https://discourse.llvm.org/t/rfc-improving-is-stmt-placement-for-better-interactive-debugging/82668 The feature is only functional in LLVM if LLVM is built with CMake flag LLVM_EXPERIMENTAL_KEY_INSTRUCTIONs. Eventually that flag will be removed.
2025-05-22[KeyInstr][Clang] Aggregate init + copy (#134639)Orlando Cazalet-Hyams1-0/+15
This patch is part of a stack that teaches Clang to generate Key Instructions metadata for C and C++. RFC: https://discourse.llvm.org/t/rfc-improving-is-stmt-placement-for-better-interactive-debugging/82668 The feature is only functional in LLVM if LLVM is built with CMake flag LLVM_EXPERIMENTAL_KEY_INSTRUCTIONs. Eventually that flag will be removed.
2025-05-21[KeyInstr][Clang] Add ApplyAtomGroup (#134632)Orlando Cazalet-Hyams1-0/+8
This is a scoped helper similar to ApplyDebugLocation that creates a new source location atom group which instructions can be added to. A source atom is a source construct that is "interesting" for debug stepping purposes. We use an atom group number to track the instruction(s) that implement the functionality for the atom, plus backup instructions/source locations. This patch is part of a stack that teaches Clang to generate Key Instructions metadata for C and C++. RFC: https://discourse.llvm.org/t/rfc-improving-is-stmt-placement-for-better-interactive-debugging/82668 The feature is only functional in LLVM if LLVM is built with CMake flag LLVM_EXPERIMENTAL_KEY_INSTRUCTIONs. Eventually that flag will be removed.
2025-05-19[cfi] Enable -fsanitize-annotate-debug-info functionality for CFI checks ↵Thurston Dang1-5/+5
(#139809) This connects the -fsanitize-annotate-debug-info plumbing (https://github.com/llvm/llvm-project/pull/138577) to CFI check codegen, using SanitizerAnnotateDebugInfo() (https://github.com/llvm/llvm-project/pull/139965) and SanitizerInfoFromCFIKind (https://github.com/llvm/llvm-project/pull/140117). Note: SanitizerAnnotateDebugInfo() is updated to a public function because it is needed in ItaniumCXXABI. Updates the tests from https://github.com/llvm/llvm-project/pull/139149.
2025-05-15[sanitizer][NFCI] Add 'SanitizerAnnotateDebugInfo' (#139965)Thurston Dang1-0/+5
This generalizes the debug info annotation code from https://github.com/llvm/llvm-project/pull/139149 and moves it into a helper function, SanitizerAnnotateDebugInfo(). Future work can use 'ApplyDebugLocation ApplyTrapDI(*this, SanitizerAnnotateDebugInfo(Ordinal));' to add annotations to additional checks.
2025-05-13[Clang][counted_by] Add support for 'counted_by' on struct pointers (#137250)Bill Wendling1-1/+19
The 'counted_by' attribute is now available for pointers in structs. It generates code for sanity checks as well as __builtin_dynamic_object_size() calculations. For example: struct annotated_ptr { int count; char *buf __attribute__((counted_by(count))); }; If the pointer's type is 'void *', use the 'sized_by' attribute, which works similarly to 'counted_by', but can handle the 'void' base type: struct annotated_ptr { int count; void *buf __attribute__((sized_by(count))); }; If the 'count' field member occurs after the pointer, use the '-fexperimental-late-parse-attributes' flag during compilation. Note that 'counted_by' cannot be applied to a pointer to an incomplete type, because the size isn't known. struct foo; struct annotated_ptr { int count; struct foo *buf __attribute__((counted_by(count))); /* invalid */ }; Signed-off-by: Bill Wendling <morbo@google.com>
2025-05-08clang: Fix broken implicit cast to generic address space (#138863)Matt Arsenault1-1/+19
This fixes emitting undefined behavior where a 64-bit generic pointer is written to a 32-bit slot allocated for a private pointer. This can be seen in test/CodeGenOpenCL/amdgcn-automatic-variable.cl's wrong_pointer_alloca.
2025-05-01[Clang][NFC] Explicitly delete copy ctor and assignment for ↵Shafik Yaghmour1-0/+3
CGAtomicOptionsRAII (#137275) Static analysis flagged CGAtomicOptionsRAII as having an explicit destructor but not having explicit copy ctor and assignment. Rule of three says we should. We are just using this as an RAII object, no need for either so they will be specified as deleted.
2025-04-18Revert "[Reland][Clang][CodeGen][UBSan] Add more precise attributes to ↵Vitaly Buka1-3/+1
recoverable ubsan handlers" (#136402) Reverts llvm/llvm-project#135135 Breaks several bots, details in #135135.
2025-04-17[Reland][Clang][CodeGen][UBSan] Add more precise attributes to recoverable ↵Yingwei Zheng1-1/+3
ubsan handlers (#135135) This patch relands https://github.com/llvm/llvm-project/pull/130990. If the check value is passed by reference, add `memory(read)`. Original PR description: This patch adds `memory(argmem: read, inaccessiblemem: readwrite)` to **recoverable** ubsan handlers in order to unblock some memory/loop optimizations. It provides an average of 3% performance improvement on llvm-test-suite (except for 49 test failures due to ubsan diagnostics).
2025-04-15[PAC] Add support for __ptrauth type qualifier (#100830)Akira Hatanaka1-3/+23
The qualifier allows programmer to directly control how pointers are signed when they are stored in a particular variable. The qualifier takes three arguments: the signing key, a flag specifying whether address discrimination should be used, and a non-negative integer that is used for additional discrimination. ``` typedef void (*my_callback)(const void*); my_callback __ptrauth(ptrauth_key_process_dependent_code, 1, 0xe27a) callback; ``` Co-Authored-By: John McCall rjmccall@apple.com
2025-04-14[clang][CodeGen] Add range metadata for atomic load of boolean type. #131476 ↵Jan Górski1-0/+3
(#133546) Fixes #131476. For `x86_64` it folds ``` movzbl t1(%rip), %eax andb $1, %al ``` into ``` movzbl t1(%rip), %eax ``` when run: `clang -S atomic-ops-load.c -o atomic-ops-load.s -O1 --target=x86_64`. But for riscv replaces: ``` lb a0, %lo(t1)(a0) andi a0, a0, 1 ``` with ``` lb a0, %lo(t1)(a0) zext.b a0, a0 ``` when run: `clang -S atomic-ops-load.c -o atomic-ops-load.s -O1 --target=riscv64`.
2025-04-11[Clang][CodeGen] Do not set inbounds flag in `EmitMemberDataPointerAddress` ↵Yingwei Zheng1-1/+1
when the base pointer is null (#130952) See also https://github.com/llvm/llvm-project/pull/130734 for the original motivation. This pattern (`container_of`) is also widely used by real-world programs. Examples: https://github.com/llvm/llvm-project/blob/1d89d7d5d76e391b035f50343e2a4890506c6f2b/llvm/include/llvm/IR/SymbolTableListTraits.h#L77-L87 https://github.com/nodejs/node/blob/a2a53cb728ec5f776ac16879ce0f480a8e838320/src/util-inl.h#L134-L137 https://github.com/search?q=*%29nullptr-%3E*&type=code
2025-04-11[Clang][CodeGen] Do not set inbounds flag for struct GEP with null base ↵Yingwei Zheng1-1/+4
pointers (#130734) In the LLVM middle-end we want to fold `gep inbounds null, idx -> null`: https://alive2.llvm.org/ce/z/5ZkPx- This pattern is common in real-world programs (https://github.com/dtcxzyw/llvm-opt-benchmark/pull/55#issuecomment-1870963906). Generally, it exists in some (actually) unreachable blocks, which is introduced by JumpThreading. However, some old-style offsetof macros are still widely used in real-world C/C++ code (e.g., hwloc/slurm/luajit). To avoid breaking existing code and inconvenience to downstream users, this patch removes the inbounds flag from the struct gep if the base pointer is null.
2025-04-10[C11] Implement WG14 N1285 (temporary lifetimes) (#133472)Aaron Ballman1-0/+2
This feature largely models the same behavior as in C++11. It is technically a breaking change between C99 and C11, so the paper is not being backported to older language modes. One difference between C++ and C is that things which are rvalues in C are often lvalues in C++ (such as the result of a ternary operator or a comma operator). Fixes #96486
2025-04-08[Clang][NFC] Move some static functions into CodeGenFunction (#134634)Orlando Cazalet-Hyams1-0/+11
Patches in the Key Instructions (KeyInstr) stack need to access CGF in these functions. 2 CGF fields are passed to these functions already; at this point it felt natural to promote them to CGF methods.
2025-04-07[DirectX] Add target builtins (#134439)Farzon Lotfi1-0/+1
- fixes #132303 - Moves dot2add from a language builtin to a target builtin. - Sets the scaffolding for Sema checks for DX builtins - Setup DirectX backend as able to have target builtins - Adds a DX TargetBuiltins emitter in `clang/lib/CodeGen/TargetBuiltins/DirectX.cpp`
2025-04-03[CodeGen] Don't include CGDebugInfo.h in CodeGenFunction.h (NFC) (#134100)Nikita Popov1-28/+4
This is an expensive header, only include it where needed. Move some functions out of line to achieve that. This reduces time to build clang by ~0.5% in terms of instructions retired.
2025-04-01[AARCH64][Neon] switch to using bitcasts in arm_neon.h where appropriate ↵Lukacma1-4/+4
(#127043) Currently arm_neon.h emits C-style casts to do vector type casts. This relies on implicit conversion between vector types to be enabled, which is currently deprecated behaviour and soon will disappear. To ensure NEON code will keep working afterwards, this patch changes all this vector type casts into bitcasts. Co-authored-by: Momchil Velikov <momchil.velikov@arm.com>
2025-03-11[Clang] Implement P0963R3 "Structured binding declaration as a condition" ↵Younan Zhang1-2/+5
(#130228) This implements the R2 semantics of P0963. The R1 semantics, as outlined in the paper, were introduced in Clang 6. In addition to that, the paper proposes swapping the evaluation order of condition expressions and the initialization of binding declarations (i.e. std::tuple-like decompositions).
2025-03-03[OpenACC] Implement 'cache' construct AST/Semaerichkeane1-0/+4
This statement level construct takes no clauses and has no associated statement, and simply labels a number of array elements as valid for caching. The implementation here is pretty simple, but it is a touch of a special case for parsing, so the parsing code reflects that.
2025-02-27Add clang atomic control options and attribute (#114841)Yaxun (Sam) Liu1-0/+42
Add option and statement attribute for controlling emitting of target-specific metadata to atomicrmw instructions in IR. The RFC for this attribute and option is https://discourse.llvm.org/t/rfc-add-clang-atomic-control-options-and-pragmas/80641, Originally a pragma was proposed, then it was changed to clang attribute. This attribute allows users to specify one, two, or all three options and must be applied to a compound statement. The attribute can also be nested, with inner attributes overriding the options specified by outer attributes or the target's default options. These options will then determine the target-specific metadata added to atomic instructions in the IR. In addition to the attribute, three new compiler options are introduced: `-f[no-]atomic-remote-memory`, `-f[no-]atomic-fine-grained-memory`, `-f[no-]atomic-ignore-denormal-mode`. These compiler options allow users to override the default options through the Clang driver and front end. `-m[no-]unsafe-fp-atomics` is aliased to `-f[no-]ignore-denormal-mode`. In terms of implementation, the atomic attribute is represented in the AST by the existing AttributedStmt, with minimal changes to AST and Sema. During code generation in Clang, the CodeGenModule maintains the current atomic options, which are used to emit the relevant metadata for atomic instructions. RAII is used to manage the saving and restoring of atomic options when entering and exiting nested AttributedStmt.
2025-02-15[HLSL] Implement HLSL intialization list support (#123141)Chris B1-0/+4
This PR implements HLSL's initialization list behvaior as specified in the draft language specifcation under [*Decl.Init.Agg*](https://microsoft.github.io/hlsl-specs/specs/hlsl.html#Decl.Init.Agg). This behavior is a bit unusual for C/C++ because intermediate braces in initializer lists are ignored and a whole array of additional conversions occur unintuitively to how initializaiton works in C. The implementaiton in this PR generates a valid C/C++ initialization list AST for the HLSL initializer so that there are no changes required to Clang's CodeGen to support this. This design will also allow us to use Clang's rewrite to convert HLSL initializers to valid C/C++ initializers that are equivalent. It does have the downside that it will generate often redundant accesses during codegen. The IR optimizer is extremely good at eliminating those so this will have no impact on the final executable performance. There is some opportunity for optimizing the initializer list generation that we could consider in subsequent commits. One notable opportunity would be to identify aggregate objects that occur in the same place in both initializers and do not require converison, those aggregates could be initialized as aggregates rather than fully scalarized. Closes #56067 --------- Co-authored-by: Finn Plummer <50529406+inbelic@users.noreply.github.com> Co-authored-by: Helena Kotas <hekotas@microsoft.com> Co-authored-by: Justin Bogner <mail@justinbogner.com>
2025-02-13[Clang] [OpenMP] Add support for '#pragma omp stripe'. (#126927)Zahira Ammarguellat1-0/+1
This patch was reviewed and approved here: https://github.com/llvm/llvm-project/pull/119891 However it has been reverted here: https://github.com/alejandro-alvarez-sonarsource/llvm-project/commit/083df25dc256154cccbc0e127d79fbac4d0583c5 due to a build issue here: https://lab.llvm.org/buildbot/#/builders/51/builds/10694 This patch is reintroducing the support.
2025-02-12[clang] run clang-format on some CGObjC files (#126644)Peter Rong1-223/+184
These files are relatively old and don't confront our formatting rules. It's hard to change them without massive clang-format changes. --------- Signed-off-by: Peter Rong <PeterRong@meta.com>
2025-02-11Revert "[Clang] [OpenMP] Add support for '#pragma omp stripe'. (#119891)"Kazu Hirata1-1/+0
This reverts commit 070f84ebc89b11df616a83a56df9ac56efbab783. Buildbot failure: https://lab.llvm.org/buildbot/#/builders/51/builds/10694
2025-02-11[Clang] [OpenMP] Add support for '#pragma omp stripe'. (#119891)Zahira Ammarguellat1-0/+1
Implement basic parsing and semantic support for `#pragma omp stripe` constuct introduced in https://www.openmp.org/wp-content/uploads/[OpenMP-API-Specification-6-0.pdf](https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-6-0.pdf), section 11.7.
2025-02-07[HLSL] Implement HLSL Elementwise casting (excluding splat cases); Re-land ↵Sarah Spall1-0/+5
#118842 (#126258) Implement HLSLElementwiseCast excluding support for splat cases Do not support casting types that contain bitfields. Partly closes https://github.com/llvm/llvm-project/issues/100609 and partly closes https://github.com/llvm/llvm-project/issues/100619 Re-land #118842 after fixing warning as an error, found by a buildbot.
2025-02-06Revert "[HLSL] Implement HLSL Flat casting (excluding splat cases)" (#126149)Sarah Spall1-5/+0
Reverts llvm/llvm-project#118842
2025-02-06[HLSL] Implement HLSL Flat casting (excluding splat cases) (#118842)Sarah Spall1-0/+5
Implement HLSLElementwiseCast excluding support for splat cases Do not support casting types that contain bitfields. Partly closes #100609 and partly closes #100619