#
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 ...
|
#
88c2af80 |
| 28-Nov-2024 |
Alexandros Lamprineas <alexandros.lamprineas@arm.com> |
[NFC][clang][FMV][TargetInfo] Refactor API for FMV feature priority. (#116257)
Currently we have code with target hooks in CodeGenModule shared between
X86 and AArch64 for sorting MultiVersionResol
[NFC][clang][FMV][TargetInfo] Refactor API for FMV feature priority. (#116257)
Currently we have code with target hooks in CodeGenModule shared between
X86 and AArch64 for sorting MultiVersionResolverOptions. Those are used
when generating IFunc resolvers for FMV. The RISCV target has different
criteria for sorting, therefore it repeats sorting after calling
CodeGenFunction::EmitMultiVersionResolver.
I am moving the FMV priority logic in TargetInfo, so that it can be
implemented by the TargetParser which then makes it possible to query it
from llvm. Here is an example why this is handy:
https://github.com/llvm/llvm-project/pull/87939
show more ...
|
#
875b10f7 |
| 22-Nov-2024 |
Pengcheng Wang <wangpengcheng.pp@bytedance.com> |
[RISCV] Support __builtin_cpu_is
We have defined `__riscv_cpu_model` variable in #101449. It contains `mvendorid`, `marchid` and `mimpid` fields which are read via system call `sys_riscv_hwprobe`.
[RISCV] Support __builtin_cpu_is
We have defined `__riscv_cpu_model` variable in #101449. It contains `mvendorid`, `marchid` and `mimpid` fields which are read via system call `sys_riscv_hwprobe`.
We can support `__builtin_cpu_is` via comparing values in compiler's CPU definitions and `__riscv_cpu_model`.
This depends on #116202.
Reviewers: lenary, BeMg, kito-cheng, preames, lukel97
Reviewed By: lenary
Pull Request: https://github.com/llvm/llvm-project/pull/116231
show more ...
|
#
d1dae1e8 |
| 22-Nov-2024 |
Mikhail Goncharov <goncharov.mikhail@gmail.com> |
Revert "[RISCV] Add mvendorid/marchid/mimpid to CPU definitions (#116202)" chain
This reverts commit b36fcf4f493ad9d30455e178076d91be99f3a7d8. This reverts commit c11b6b1b8af7454b35eef342162dc2cddf5
Revert "[RISCV] Add mvendorid/marchid/mimpid to CPU definitions (#116202)" chain
This reverts commit b36fcf4f493ad9d30455e178076d91be99f3a7d8. This reverts commit c11b6b1b8af7454b35eef342162dc2cddf54b4de. This reverts commit 775148f2367600f90d28684549865ee9ea2f11be.
multiple bot build breakages, e.g. https://lab.llvm.org/buildbot/#/builders/3/builds/8076
show more ...
|
#
c11b6b1b |
| 22-Nov-2024 |
Pengcheng Wang <wangpengcheng.pp@bytedance.com> |
[RISCV] Support __builtin_cpu_is
We have defined `__riscv_cpu_model` variable in #101449. It contains `mvendorid`, `marchid` and `mimpid` fields which are read via system call `sys_riscv_hwprobe`.
[RISCV] Support __builtin_cpu_is
We have defined `__riscv_cpu_model` variable in #101449. It contains `mvendorid`, `marchid` and `mimpid` fields which are read via system call `sys_riscv_hwprobe`.
We can support `__builtin_cpu_is` via comparing values in compiler's CPU definitions and `__riscv_cpu_model`.
This depends on #116202.
Reviewers: lenary, BeMg, kito-cheng, preames, lukel97
Reviewed By: lenary
Pull Request: https://github.com/llvm/llvm-project/pull/116231
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 ...
|
#
7475156d |
| 07-Nov-2024 |
Bill Wendling <morbo@google.com> |
[Clang] Add __builtin_counted_by_ref builtin (#114495)
The __builtin_counted_by_ref builtin is used on a flexible array
pointer and returns a pointer to the "counted_by" attribute's COUNT
argument
[Clang] Add __builtin_counted_by_ref builtin (#114495)
The __builtin_counted_by_ref builtin is used on a flexible array
pointer and returns a pointer to the "counted_by" attribute's COUNT
argument, which is a field in the same non-anonymous struct as the
flexible array member. This is useful for automatically setting the
count field without needing the programmer's intervention. Otherwise
it's possible to get this anti-pattern:
ptr = alloc(<ty>, ..., COUNT);
ptr->FAM[9] = 42; /* <<< Sanitizer will complain */
ptr->count = COUNT;
To prevent this anti-pattern, the user can create an allocator that
automatically performs the assignment:
#define alloc(TY, FAM, COUNT) ({ \
TY __p = alloc(get_size(TY, COUNT)); \
if (__builtin_counted_by_ref(__p->FAM)) \
*__builtin_counted_by_ref(__p->FAM) = COUNT; \
__p; \
})
The builtin's behavior is heavily dependent upon the "counted_by"
attribute existing. It's main utility is during allocation to avoid
the above anti-pattern. If the flexible array member doesn't have that
attribute, the builtin becomes a no-op. Therefore, if the flexible
array member has a "count" field not referenced by "counted_by", it
must be set explicitly after the allocation as this builtin will
return a "nullptr" and the assignment will most likely be elided.
---------
Co-authored-by: Bill Wendling <isanbard@gmail.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
show more ...
|
#
481bce01 |
| 28-Oct-2024 |
joaosaffran <126493771+joaosaffran@users.noreply.github.com> |
Adding splitdouble HLSL function (#109331)
- Adding hlsl `splitdouble` intrinsics
- Adding DXIL lowering
- Adding SPIRV lowering
- Adding test
Fixes: #108901
---------
Co-authored-by: Jo
Adding splitdouble HLSL function (#109331)
- Adding hlsl `splitdouble` intrinsics
- Adding DXIL lowering
- Adding SPIRV lowering
- Adding test
Fixes: #108901
---------
Co-authored-by: Joao Saffran <jderezende@microsoft.com>
show more ...
|
#
4dd55c56 |
| 24-Oct-2024 |
Jay Foad <jay.foad@amd.com> |
[clang] Use {} instead of std::nullopt to initialize empty ArrayRef (#109399)
Follow up to #109133.
|
#
51b4ada4 |
| 17-Oct-2024 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
clang/AMDGPU: Set noalias.addrspace metadata on atomicrmw (#102462)
|
#
d8df1185 |
| 01-Oct-2024 |
Sarah Spall <sarahspall@microsoft.com> |
[HLSL] Array by-value assignment (#109323)
Make Constant Arrays in HLSL assignable.
Closes #109043
|
#
0c31ea5a |
| 25-Sep-2024 |
Paul Walker <paul.walker@arm.com> |
[Clang][SME2] Use tuple result of SME builtins directly. (#109423)
I missed a codepath during PR108008 so SME2/SVE2p1 builtins are
converting their struct return type into a large vector, which is
[Clang][SME2] Use tuple result of SME builtins directly. (#109423)
I missed a codepath during PR108008 so SME2/SVE2p1 builtins are
converting their struct return type into a large vector, which is
causing unnecessary casting via memory.
show more ...
|
#
53907ed5 |
| 25-Sep-2024 |
Benjamin Maxwell <benjamin.maxwell@arm.com> |
[clang][codegen] Don't mark "int" TBAA on FP libcalls with indirect args (#108853)
On some targets, an FP libcall with argument types such as long double will be lowered to pass arguments indirectly
[clang][codegen] Don't mark "int" TBAA on FP libcalls with indirect args (#108853)
On some targets, an FP libcall with argument types such as long double will be lowered to pass arguments indirectly via pointers. When this is the case we should not mark the libcall with "int" TBAA as it may lead to incorrect optimizations.
Currently, this can be seen for long doubles on x86_64-w64-mingw32. The `load x86_fp80` after the call is (incorrectly) marked with "int" TBAA (overwriting the previous metadata for "long double").
Nothing seems to break due to this currently as the metadata is being incorrectly placed on the load and not the call. But if the metadata is moved to the call (which this patch ensures), LLVM will optimize out the setup for the arguments.
show more ...
|
#
d8f555d6 |
| 25-Sep-2024 |
Yingwei Zheng <dtcxzyw2333@gmail.com> |
[UBSan] Diagnose assumption violation (#104741)
This patch extends [D34590](https://reviews.llvm.org/D34590) to check
assumption violations.
---------
Co-authored-by: Vitaly Buka <vitalybuka@
[UBSan] Diagnose assumption violation (#104741)
This patch extends [D34590](https://reviews.llvm.org/D34590) to check
assumption violations.
---------
Co-authored-by: Vitaly Buka <vitalybuka@google.com>
show more ...
|
#
d7c69c20 |
| 19-Sep-2024 |
David Pagan <dave.pagan@amd.com> |
[clang][OpenMP] Add codegen for scope directive (#109197)
Added codegen for scope directive, enabled allocate and firstprivate
clauses, and added scope directive LIT test.
Testing
- LIT tests
[clang][OpenMP] Add codegen for scope directive (#109197)
Added codegen for scope directive, enabled allocate and firstprivate
clauses, and added scope directive LIT test.
Testing
- LIT tests (including new scope test).
- OpenMP scope example test from 5.2 OpenMP API examples document.
- Three executable scope tests from OpenMP_VV/sollve_vv suite.
show more ...
|
Revision tags: llvmorg-19.1.0 |
|
#
992a64aa |
| 13-Sep-2024 |
Paul Walker <paul.walker@arm.com> |
[Clang][SVE] Change LLVM representation of ACLE tuple types to be struct based. (#108008)
This implements our original design now that LLVM is comfortable with
structs and arrays of scalable vector
[Clang][SVE] Change LLVM representation of ACLE tuple types to be struct based. (#108008)
This implements our original design now that LLVM is comfortable with
structs and arrays of scalable vector types. All SVE ACLE intrinsics
already use struct types so the effect of this change is purely the
types used for alloca and function parameters.
There should be no C/C++ user visible change with this patch.
show more ...
|
#
9cd93774 |
| 13-Sep-2024 |
Piyou Chen <piyou.chen@sifive.com> |
[RISCV][FMV] Support target_clones (#85786)
This patch enable the function multiversion(FMV) and `target_clones`
attribute for RISC-V target.
The proposal of `target_clones` syntax can be found
[RISCV][FMV] Support target_clones (#85786)
This patch enable the function multiversion(FMV) and `target_clones`
attribute for RISC-V target.
The proposal of `target_clones` syntax can be found at the
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/48 (which has
landed), as modified by the proposed
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/85 (which adds the
priority syntax).
It supports the `target_clones` function attribute and function
multiversioning feature for RISC-V target. It will generate the ifunc
resolver function for the function that declared with target_clones
attribute.
The resolver function will check the version support by runtime object
`__riscv_feature_bits`.
For example:
```
__attribute__((target_clones("default", "arch=+ver1", "arch=+ver2"))) int bar() {
return 1;
}
```
the corresponding resolver will be like:
```
bar.resolver() {
__init_riscv_feature_bits();
// Check arch=+ver1
if ((__riscv_feature_bits.features[0] & BITMASK_OF_VERSION1) == BITMASK_OF_VERSION1) {
return bar.arch=+ver1;
} else {
// Check arch=+ver2
if ((__riscv_feature_bits.features[0] & BITMASK_OF_VERSION2) == BITMASK_OF_VERSION2) {
return bar.arch=+ver2;
} else {
// Default
return bar.default;
}
}
}
```
show more ...
|
#
0f349b7a |
| 09-Sep-2024 |
Sarah Spall <spall@users.noreply.github.com> |
[HLSL] Implement support for HLSL intrinsic - select (#107129)
Implement support for HLSL intrinsic select.
This would close issue #75377
|
#
e17a39bc |
| 09-Sep-2024 |
Yuxuan Chen <ych@fb.com> |
[Clang] C++20 Coroutines: Introduce Frontend Attribute [[clang::coro_await_elidable]] (#99282)
This patch is the frontend implementation of the coroutine elide
improvement project detailed in this
[Clang] C++20 Coroutines: Introduce Frontend Attribute [[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
show more ...
|
#
13546c28 |
| 08-Sep-2024 |
Kazu Hirata <kazu@google.com> |
[CodeGen] Avoid repeated hash lookups (NFC) (#107736)
|
Revision tags: 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 ...
|
#
96509bb9 |
| 23-Aug-2024 |
Florian Hahn <flo@fhahn.com> |
[Matrix] Preserve signedness when extending matrix index expression. (#103044)
As per [1] the indices for a matrix element access operator shall have
integral or unscoped enumeration types and be n
[Matrix] Preserve signedness when extending matrix index expression. (#103044)
As per [1] the indices for a matrix element access operator shall have
integral or unscoped enumeration types and be non-negative. At the
moment, the index expression is converted to SizeType irrespective of
the signedness of the index expression. This causes implicit sign
conversion warnings if any of the indices is signed.
As per the spec, using signed types as indices is allowed and should not
cause any warnings. If the index expression is signed, extend to
SignedSizeType to avoid the warning.
[1]
https://clang.llvm.org/docs/MatrixTypes.html#matrix-type-element-access-operator
PR: https://github.com/llvm/llvm-project/pull/103044
show more ...
|
#
126b56a2 |
| 21-Aug-2024 |
Piyou Chen <piyou.chen@sifive.com> |
[RISCV] Make EmitRISCVCpuSupports accept multiple features (#104917)
This patch creates an additional EmitRISCVCpuSupports function to handle
situations with multiple features. It also modifies the
[RISCV] Make EmitRISCVCpuSupports accept multiple features (#104917)
This patch creates an additional EmitRISCVCpuSupports function to handle
situations with multiple features. It also modifies the original
EmitRISCVCpuSupports function to invoke the new one.
show more ...
|
Revision tags: llvmorg-19.1.0-rc3 |
|
#
94b8b11a |
| 15-Aug-2024 |
Bill Wendling <morbo@google.com> |
[Clang][NFC] Move FindCountedByField into FieldDecl (#104235)
FindCountedByField can be used in more places than CodeGen. Move it into
FieldDecl to avoid layering issues.
|
#
92aec519 |
| 09-Aug-2024 |
Jeremy Morse <jeremy.morse@sony.com> |
[DebugInfo][RemoveDIs] Use iterator-inserters in clang (#102006)
As part of the LLVM effort to eliminate debug-info intrinsics, we're
moving to a world where only iterators should be used to insert
[DebugInfo][RemoveDIs] Use iterator-inserters in clang (#102006)
As part of the LLVM effort to eliminate debug-info intrinsics, we're
moving to a world where only iterators should be used to insert
instructions. This isn't a problem in clang when instructions get
generated before any debug-info is inserted, however we're planning on
deprecating and removing the instruction-pointer insertion routines.
Scatter some calls to getIterator in a few places, remove a
deref-then-addrof on another iterator, and add an overload for the
createLoadInstBefore utility. Some callers passes a null insertion
point, which we need to handle explicitly now.
show more ...
|