#
abc8812d |
| 29-Jan-2025 |
Jason Rice <ricejasonf@gmail.com> |
[Clang][P1061] Add stuctured binding packs (#121417)
This is an implementation of P1061 Structure Bindings Introduce a Pack without the ability to use packs outside of templates. There is a couple o
[Clang][P1061] Add stuctured binding packs (#121417)
This is an implementation of P1061 Structure Bindings Introduce a Pack without the ability to use packs outside of templates. There is a couple of ways the AST could have been sliced so let me know what you think. The only part of this change that I am unsure of is the serialization/deserialization stuff. I followed the implementation of other Exprs, but I do not really know how it is tested. Thank you for your time considering this.
---------
Co-authored-by: Yanzuo Liu <zwuis@outlook.com>
show more ...
|
Revision tags: llvmorg-21-init |
|
#
8fb42300 |
| 22-Jan-2025 |
Tom Honermann <tom.honermann@intel.com> |
[SYCL] AST support for SYCL kernel entry point functions. (#122379)
A SYCL kernel entry point function is a non-member function or a static
member function declared with the `sycl_kernel_entry_poin
[SYCL] AST support for SYCL kernel entry point functions. (#122379)
A SYCL kernel entry point function is a non-member function or a static
member function declared with the `sycl_kernel_entry_point` attribute.
Such functions define a pattern for an offload kernel entry point
function to be generated to enable execution of a SYCL kernel on a
device. A SYCL library implementation orchestrates the invocation of
these functions with corresponding SYCL kernel arguments in response to
calls to SYCL kernel invocation functions specified by the SYCL 2020
specification.
The offload kernel entry point function (sometimes referred to as the
SYCL kernel caller function) is generated from the SYCL kernel entry
point function by a transformation of the function parameters followed
by a transformation of the function body to replace references to the
original parameters with references to the transformed ones. Exactly how
parameters are transformed will be explained in a future change that
implements non-trivial transformations. For now, it suffices to state
that a given parameter of the SYCL kernel entry point function may be
transformed to multiple parameters of the offload kernel entry point as
needed to satisfy offload kernel argument passing requirements.
Parameters that are decomposed in this way are reconstituted as local
variables in the body of the generated offload kernel entry point
function.
For example, given the following SYCL kernel entry point function
definition:
```
template<typename KernelNameType, typename KernelType>
[[clang::sycl_kernel_entry_point(KernelNameType)]]
void sycl_kernel_entry_point(KernelType kernel) {
kernel();
}
```
and the following call:
```
struct Kernel {
int dm1;
int dm2;
void operator()() const;
};
Kernel k;
sycl_kernel_entry_point<class kernel_name>(k);
```
the corresponding offload kernel entry point function that is generated
might look as follows (assuming `Kernel` is a type that requires
decomposition):
```
void offload_kernel_entry_point_for_kernel_name(int dm1, int dm2) {
Kernel kernel{dm1, dm2};
kernel();
}
```
Other details of the generated offload kernel entry point function, such
as its name and calling convention, are implementation details that need
not be reflected in the AST and may differ across target devices. For
that reason, only the transformation described above is represented in
the AST; other details will be filled in during code generation.
These transformations are represented using new AST nodes introduced
with this change. `OutlinedFunctionDecl` holds a sequence of
`ImplicitParamDecl` nodes and a sequence of statement nodes that
correspond to the transformed parameters and function body.
`SYCLKernelCallStmt` wraps the original function body and associates it
with an `OutlinedFunctionDecl` instance. For the example above, the AST
generated for the `sycl_kernel_entry_point<kernel_name>` specialization
would look as follows:
```
FunctionDecl 'sycl_kernel_entry_point<kernel_name>(Kernel)'
TemplateArgument type 'kernel_name'
TemplateArgument type 'Kernel'
ParmVarDecl kernel 'Kernel'
SYCLKernelCallStmt
CompoundStmt
<original statements>
OutlinedFunctionDecl
ImplicitParamDecl 'dm1' 'int'
ImplicitParamDecl 'dm2' 'int'
CompoundStmt
VarDecl 'kernel' 'Kernel'
<initialization of 'kernel' with 'dm1' and 'dm2'>
<transformed statements with redirected references of 'kernel'>
```
Any ODR-use of the SYCL kernel entry point function will (with future
changes) suffice for the offload kernel entry point to be emitted. An
actual call to the SYCL kernel entry point function will result in a
call to the function. However, evaluation of a `SYCLKernelCallStmt`
statement is a no-op, so such calls will have no effect other than to
trigger emission of the offload kernel entry point.
Additionally, as a related change inspired by code review feedback,
these changes disallow use of the `sycl_kernel_entry_point` attribute
with functions defined with a _function-try-block_. The SYCL 2020
specification prohibits the use of C++ exceptions in device functions.
Even if exceptions were not prohibited, it is unclear what the semantics
would be for an exception that escapes the SYCL kernel entry point
function; the boundary between host and device code could be an implicit
noexcept boundary that results in program termination if violated, or
the exception could perhaps be propagated to host code via the SYCL
library. Pending support for C++ exceptions in device code and clear
semantics for handling them at the host-device boundary, this change
makes use of the `sycl_kernel_entry_point` attribute with a function
defined with a _function-try-block_ an error.
show more ...
|
Revision tags: llvmorg-19.1.7 |
|
#
5ff7f479 |
| 09-Jan-2025 |
Aaron Ballman <aaron@aaronballman.com> |
[C++20] Destroying delete and deleted destructors (#118800)
When a destroying delete overload is selected, the destructor is not
automatically called. Therefore, the destructor can be deleted witho
[C++20] Destroying delete and deleted destructors (#118800)
When a destroying delete overload is selected, the destructor is not
automatically called. Therefore, the destructor can be deleted without
causing the program to be ill-formed.
Fixes #46818
show more ...
|
#
db81e8c4 |
| 06-Jan-2025 |
erichkeane <ekeane@nvidia.com> |
[OpenACC] Initial sema implementation of 'update' construct
This executable construct has a larger list of clauses than some of the others, plus has some additional restrictions. This patch impleme
[OpenACC] Initial sema implementation of 'update' construct
This executable construct has a larger list of clauses than some of the others, plus has some additional restrictions. This patch implements the AST node, plus the 'cannot be the body of a if, while, do, switch, or label' statement restriction. Future patches will handle the rest of the restrictions, which are based on clauses.
show more ...
|
#
21c785d7 |
| 03-Jan-2025 |
erichkeane <ekeane@nvidia.com> |
[OpenACC] Implement 'set' construct sema
The 'set' construct is another fairly simple one, it doesn't have an associated statement and only a handful of allowed clauses. This patch implements it and
[OpenACC] Implement 'set' construct sema
The 'set' construct is another fairly simple one, it doesn't have an associated statement and only a handful of allowed clauses. This patch implements it and all the rules for it, allowing 3 of its for clauses. The only exception is default_async, which will be implemented in a future patch, because it isn't just being enabled, it needs a complete new implementation.
show more ...
|
#
4bbdb018 |
| 19-Dec-2024 |
erichkeane <ekeane@nvidia.com> |
[OpenACC] Implement 'init' and 'shutdown' constructs
These two constructs are very simple and similar, and only support 3 different clauses, two of which are already implemented. This patch adds AS
[OpenACC] Implement 'init' and 'shutdown' constructs
These two constructs are very simple and similar, and only support 3 different clauses, two of which are already implemented. This patch adds AST nodes for both constructs, and leaves the device_num clause unimplemented, but enables the other two.
show more ...
|
#
e34cc7c9 |
| 17-Dec-2024 |
erichkeane <ekeane@nvidia.com> |
[OpenACC] Implement 'wait' construct
The arguments to this are the same as for the 'wait' clause, so this reuses all of that infrastructure. So all this has to do is support a pair of clauses that a
[OpenACC] Implement 'wait' construct
The arguments to this are the same as for the 'wait' clause, so this reuses all of that infrastructure. So all this has to do is support a pair of clauses that are already implemented (if and async), plus create an AST node. This patch does so, and adds proper testing.
show more ...
|
Revision tags: llvmorg-19.1.6 |
|
#
010d0115 |
| 10-Dec-2024 |
erichkeane <ekeane@nvidia.com> |
[OpenACC] Create AST nodes for 'data' constructs
These constructs are all very similar and closely related, so this patch creates the AST nodes for them, serialization, printing/etc. Additionally th
[OpenACC] Create AST nodes for 'data' constructs
These constructs are all very similar and closely related, so this patch creates the AST nodes for them, serialization, printing/etc. Additionally the restrictions are all added as tests/todos in the tests, as those will have to be implemented once we get those clauses implemented.
show more ...
|
#
91354fb1 |
| 05-Dec-2024 |
Aaron Ballman <aaron@aaronballman.com> |
[C++20] Destroying delete can cause a type to be noexcept when deleting (#118687)
Given a `noexcept` operator with an operand that calls `delete`, Clang
was not considering whether the selected `op
[C++20] Destroying delete can cause a type to be noexcept when deleting (#118687)
Given a `noexcept` operator with an operand that calls `delete`, Clang
was not considering whether the selected `operator delete` function was
a destroying delete or not when inspecting whether the deleted object
type has a throwing destructor. Thus, the operator would return `false`
for a type with a potentially throwing destructor even though that
destructor would not be called due to the destroying delete. Clang now
takes the kind of delete operator into consideration.
Fixes #118660
show more ...
|
Revision tags: llvmorg-19.1.5, llvmorg-19.1.4 |
|
#
46d750be |
| 16-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[Sema] Remove unused includes (NFC) (#116461)
Identified with misc-include-cleaner.
|
#
b9d678d2 |
| 15-Nov-2024 |
Joseph Huber <huberjn@outlook.com> |
[Clang] Use TargetInfo when deciding if an address space is compatible (#115777)
Summary: Address spaces are used in several embedded and GPU targets to describe accesses to different types of memo
[Clang] Use TargetInfo when deciding if an address space is compatible (#115777)
Summary: Address spaces are used in several embedded and GPU targets to describe accesses to different types of memory. Currently we use the address space enumerations to control which address spaces are considered supersets of eachother, however this is also a target level property as described by the C standard's passing mentions. This patch allows the address space checks to use the target information to decide if a pointer conversion is legal. For AMDGPU and NVPTX, all supported address spaces can be converted to the default address space.
More semantic checks can be added on top of this, for now I'm mainly looking to get more standard semantics working for C/C++. Right now the address space conversions must all be done explicitly in C/C++ unlike the offloading languages which define their own custom address spaces that just map to the same target specific ones anyway. The main question is if this behavior is a function of the target or the language.
show more ...
|
#
39351f8e |
| 07-Nov-2024 |
erichkeane <ekeane@nvidia.com> |
[OpenACC] Implement AST/Sema for combined constructs
Combined constructs (OpenACC 3.3 section 2.11) are a short-cut for writing a `loop` construct immediately inside of a `compute` construct. Howeve
[OpenACC] Implement AST/Sema for combined constructs
Combined constructs (OpenACC 3.3 section 2.11) are a short-cut for writing a `loop` construct immediately inside of a `compute` construct. However, this interaction requires we do additional work to ensure that we get the semantics between the two correct, as well as diagnostics.
This patch adds the semantic analysis for the constructs (but no clauses), as well as the AST nodes.
show more ...
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2 |
|
#
d412cea8 |
| 03-Oct-2024 |
Erich Keane <ekeane@nvidia.com> |
[OpenACC] Implement 'tile' attribute AST (#110999)
The 'tile' clause shares quite a bit of the rules with 'collapse', so a
followup patch will add those tests/behaviors. This patch deals with
addi
[OpenACC] Implement 'tile' attribute AST (#110999)
The 'tile' clause shares quite a bit of the rules with 'collapse', so a
followup patch will add those tests/behaviors. This patch deals with
adding the AST node.
The 'tile' clause takes a series of integer constant expressions, or *.
The asterisk is now represented by a new OpenACCAsteriskSizeExpr node,
else this clause is very similar to others.
show more ...
|
Revision tags: llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4 |
|
#
89fb8490 |
| 31-Aug-2024 |
Chris B <chris.bieneman@me.com> |
[HLSL] Implement output parameter (#101083)
HLSL output parameters are denoted with the `inout` and `out` keywords
in the function declaration. When an argument to an output parameter is
construct
[HLSL] Implement output parameter (#101083)
HLSL output parameters are denoted with the `inout` and `out` keywords
in the function declaration. When an argument to an output parameter is
constructed a temporary value is constructed for the argument.
For `inout` pamameters the argument is initialized via copy-initialization
from the argument lvalue expression to the parameter type. For `out`
parameters the argument is not initialized before the call.
In both cases on return of the function the temporary value is written
back to the argument lvalue expression through an implicit assignment
binary operator with casting as required.
This change introduces a new HLSLOutArgExpr ast node which represents
the output argument behavior. The OutArgExpr has three defined children:
- An OpaqueValueExpr of the argument lvalue expression.
- An OpaqueValueExpr of the copy-initialized parameter.
- A BinaryOpExpr assigning the first with the value of the second.
Fixes #87526
---------
Co-authored-by: Damyan Pepper <damyanp@microsoft.com>
Co-authored-by: John McCall <rjmccall@gmail.com>
show more ...
|
Revision tags: llvmorg-19.1.0-rc3 |
|
#
31bb759d |
| 05-Aug-2024 |
Haojian Wu <hokein.wu@gmail.com> |
Fix an unused variable and -Wswitch warning after a42e515e3a9f3bb4e44389c097b89104d95b9b29
|
Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
5c93a94f |
| 19-Jul-2024 |
Michael Kruse <llvm-project@meinersbur.de> |
[Clang][OpenMP] Add interchange directive (#93022)
Add the interchange directive which will be introduced in the upcoming
OpenMP 6.0 specification. A preview has been published in [Technical
Repor
[Clang][OpenMP] Add interchange directive (#93022)
Add the interchange directive which will be introduced in the upcoming
OpenMP 6.0 specification. A preview has been published in [Technical
Report 12](https://www.openmp.org/wp-content/uploads/openmp-TR12.pdf).
show more ...
|
#
80865c01 |
| 18-Jul-2024 |
Michael Kruse <llvm-project@meinersbur.de> |
[Clang][OpenMP] Add reverse directive (#92916)
Add the reverse directive which will be introduced in the upcoming
OpenMP 6.0 specification. A preview has been published in [Technical
Report 12](ht
[Clang][OpenMP] Add reverse directive (#92916)
Add the reverse directive which will be introduced in the upcoming
OpenMP 6.0 specification. A preview has been published in [Technical
Report 12](https://www.openmp.org/wp-content/uploads/openmp-TR12.pdf).
---------
Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
show more ...
|
#
bae2c549 |
| 01-Jul-2024 |
Vlad Serebrennikov <serebrennikov.vladislav@gmail.com> |
[clang][NFC] Move documentation of `Sema` functions into `Sema.h`
This patch moves documentation of `Sema` functions from `.cpp` files to `Sema.h` when there was no documentation in the latter, or i
[clang][NFC] Move documentation of `Sema` functions into `Sema.h`
This patch moves documentation of `Sema` functions from `.cpp` files to `Sema.h` when there was no documentation in the latter, or it can be trivially subsumed. More complicated cases when there's less trivial divergence between documentation attached to declaration and the one attached to implementation are left for a later PR that would require review.
It appears that doxygen can find the documentation for a function defined out-of-line even if it's attached to an implementation, and not declaration. But other tools, e.g. clangd, are not as powerful. So this patch significantly improves autocompletion experience for (at least) clangd-based IDEs.
show more ...
|
#
b608b223 |
| 20-Jun-2024 |
Mital Ashok <mital@mitalashok.co.uk> |
[Clang] [Sema] Ensure noexcept(typeid(E)) checks if E throws when needed (#95846)
3ad31e12ccfc7db25f3cbedc4ee966e7099ac78f changed it so that not all
potentially-evaluated `typeid`s were marked as
[Clang] [Sema] Ensure noexcept(typeid(E)) checks if E throws when needed (#95846)
3ad31e12ccfc7db25f3cbedc4ee966e7099ac78f changed it so that not all
potentially-evaluated `typeid`s were marked as potentially-throwing, but
I forgot to check the subexpression if the null check of the `typeid`
didn't potentially-throw. This adds that check.
show more ...
|
#
41c6e437 |
| 20-Jun-2024 |
Mariya Podchishchaeva <mariya.podchishchaeva@intel.com> |
Reland [clang][Sema, Lex, Parse] Preprocessor embed in C and C++ (#95802)
This commit implements the entirety of the now-accepted [N3017
-Preprocessor
Embed](https://www.open-std.org/jtc1/sc22/wg1
Reland [clang][Sema, Lex, Parse] Preprocessor embed in C and C++ (#95802)
This commit implements the entirety of the now-accepted [N3017
-Preprocessor
Embed](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm) and
its sister C++ paper [p1967](https://wg21.link/p1967). It implements
everything in the specification, and includes an implementation that
drastically improves the time it takes to embed data in specific
scenarios (the initialization of character type arrays). The mechanisms
used to do this are used under the "as-if" rule, and in general when the
system cannot detect it is initializing an array object in a variable
declaration, will generate EmbedExpr AST node which will be expanded by
AST consumers (CodeGen or constant expression evaluators) or expand
embed directive as a comma expression.
This reverts commit
https://github.com/llvm/llvm-project/commit/682d461d5a231cee54d65910e6341769419a67d7.
---------
Co-authored-by: The Phantom Derpstorm <phdofthehouse@gmail.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Co-authored-by: H. Vetinari <h.vetinari@gmx.com>
show more ...
|
#
3ad31e12 |
| 17-Jun-2024 |
Mital Ashok <mital@mitalashok.co.uk> |
[Clang] Introduce `CXXTypeidExpr::hasNullCheck` (#95718)
Used to implement CWG2191 where `typeid` for a polymorphic glvalue only
becomes potentially-throwing if the `typeid` operand was already
po
[Clang] Introduce `CXXTypeidExpr::hasNullCheck` (#95718)
Used to implement CWG2191 where `typeid` for a polymorphic glvalue only
becomes potentially-throwing if the `typeid` operand was already
potentially throwing or a `nullptr` check was inserted:
https://cplusplus.github.io/CWG/issues/2191.html
Also change `Expr::hasSideEffects` for `CXXTypeidExpr` to check the
operand for side-effects instead of always reporting that there are
side-effects
Remove `IsDeref` parameter of `CGCXXABI::shouldTypeidBeNullChecked`
because it should never return `true` if `!IsDeref` (we shouldn't add a
null check that wasn't there in the first place)
show more ...
|
Revision tags: llvmorg-18.1.8 |
|
#
682d461d |
| 12-Jun-2024 |
Vitaly Buka <vitalybuka@google.com> |
Revert "✨ [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy)" (#95299)
Reverts llvm/llvm-project#68620
Introduce or expose a memory leak and UB, see llvm/llvm-pro
Revert "✨ [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy)" (#95299)
Reverts llvm/llvm-project#68620
Introduce or expose a memory leak and UB, see llvm/llvm-project#68620
show more ...
|
#
5989450e |
| 12-Jun-2024 |
The Phantom Derpstorm <phdofthehouse@gmail.com> |
[clang][Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (#68620)
This commit implements the entirety of the now-accepted [N3017 -
Preprocessor
Embed](https://www
[clang][Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (#68620)
This commit implements the entirety of the now-accepted [N3017 -
Preprocessor
Embed](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm) and
its sister C++ paper [p1967](https://wg21.link/p1967). It implements
everything in the specification, and includes an implementation that
drastically improves the time it takes to embed data in specific
scenarios (the initialization of character type arrays). The mechanisms
used to do this are used under the "as-if" rule, and in general when the
system cannot detect it is initializing an array object in a variable
declaration, will generate EmbedExpr AST node which will be expanded
by AST consumers (CodeGen or constant expression evaluators) or
expand embed directive as a comma expression.
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Co-authored-by: H. Vetinari <h.vetinari@gmx.com>
Co-authored-by: Podchishchaeva, Mariya <mariya.podchishchaeva@intel.com>
show more ...
|
Revision tags: llvmorg-18.1.7 |
|
#
42f4e505 |
| 05-Jun-2024 |
Erich Keane <ekeane@nvidia.com> |
[OpenACC] Loop construct basic Sema and AST work (#93742)
This patch implements the 'loop' construct AST, as well as the basic
appertainment rule. Additionally, it sets up the 'parent' compute
con
[OpenACC] Loop construct basic Sema and AST work (#93742)
This patch implements the 'loop' construct AST, as well as the basic
appertainment rule. Additionally, it sets up the 'parent' compute
construct, which is necessary for codegen/other diagnostics.
A 'loop' can apply to a for or range-for loop, otherwise it has no other
restrictions (though some of its clauses do).
show more ...
|
Revision tags: llvmorg-18.1.6, llvmorg-18.1.5 |
|
#
f061a395 |
| 30-Apr-2024 |
Krystian Stasiowski <sdkrystian@gmail.com> |
[Clang][Sema][Parse] Delay parsing of noexcept-specifiers in friend function declarations (#90517)
According to [class.mem.general] p8:
> A complete-class context of a class (template) is a
> - fu
[Clang][Sema][Parse] Delay parsing of noexcept-specifiers in friend function declarations (#90517)
According to [class.mem.general] p8:
> A complete-class context of a class (template) is a
> - function body,
> - default argument,
> - default template argument,
> - _noexcept-specifier_, or
> - default member initializer
>
> within the member-specification of the class or class template.
When testing #90152, it came to my attention that we do _not_ consider
the _noexcept-specifier_ of a friend function declaration to be a
complete-class context (something which the Microsoft standard library
depends on). Although a comment states that this is "consistent with
what other implementations do", the only other implementation that
exhibits this behavior is GCC (MSVC and EDG both late-parse the
_noexcept-specifier_).
This patch changes _noexcept-specifiers_ of friend function declarations
to be late parsed, which is in agreement with the standard & majority of
implementations. Pre-#90152, our existing implementation falls "in
between" the implementation consensus: within non-template classes, we
would not find latter declared members (qualified and unqualified),
while within class templates we would not find latter declared member
when named with a unqualified name, we would find members named with a
qualified name (even when lookup context is the current instantiation).
Therefore, this _shouldn't_ be a breaking change -- any code that didn't
compile will continue to not compile (since a _noexcept-specifier_ is
not part of the deduction substitution
loci (see [temp.deduct.general] p7), and any code which
did compile should continue to do so.
show more ...
|