Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4 |
|
#
e8a66243 |
| 16-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[CodeGen] Remove unused includes (NFC) (#116459)
Identified with misc-include-cleaner.
|
#
6bd3f2e8 |
| 14-Nov-2024 |
Eli Friedman <efriedma@quicinc.com> |
[clang codegen] Add CreateRuntimeFunction overload that takes a clang type. (#113506)
Correctly computing the LLVM types/attributes is complicated in general,
so add a variant which does that for y
[clang codegen] Add CreateRuntimeFunction overload that takes a clang type. (#113506)
Correctly computing the LLVM types/attributes is complicated in general,
so add a variant which does that for you.
show more ...
|
#
463a4c16 |
| 30-Oct-2024 |
Jay Foad <jay.foad@amd.com> |
[clang] Remove some uses of llvm::StructType::setBody. NFC. (#113691)
It is simple to create the struct body up front, now that we have
transitioned to opaque pointers.
|
Revision tags: llvmorg-19.1.3 |
|
#
6e0b0038 |
| 22-Oct-2024 |
Alex Voicu <alexandru.voicu@amd.com> |
[clang][OpenCL][CodeGen][AMDGPU] Do not use `private` as the default AS for when `generic` is available (#112442)
Currently, for AMDGPU, when compiling for OpenCL, we unconditionally use
`private`
[clang][OpenCL][CodeGen][AMDGPU] Do not use `private` as the default AS for 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.
show more ...
|
Revision tags: llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0 |
|
#
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 ...
|
Revision tags: llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
997e5e87 |
| 09-Jul-2024 |
Akira Hatanaka <ahatanak@gmail.com> |
[CodeGen] Add a flag to disable emitting block signature strings (#96944)
Users who don't need the signature string to be emitted can use the flag
to reduce code size.
rdar://121933818
|
#
d75f9dd1 |
| 24-Jun-2024 |
Stephen Tozer <stephen.tozer@sony.com> |
Revert "[IR][NFC] Update IRBuilder to use InsertPosition (#96497)"
Reverts the above commit, as it updates a common header function and did not update all callsites:
https://lab.llvm.org/buildbot
Revert "[IR][NFC] Update IRBuilder to use InsertPosition (#96497)"
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.
show more ...
|
#
6481dc57 |
| 24-Jun-2024 |
Stephen Tozer <stephen.tozer@sony.com> |
[IR][NFC] Update IRBuilder to use InsertPosition (#96497)
Uses the new InsertPosition class (added in #94226) to simplify some of
the IRBuilder interface, and removes the need to pass a BasicBlock
[IR][NFC] Update IRBuilder to use InsertPosition (#96497)
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.
show more ...
|
Revision tags: llvmorg-18.1.8 |
|
#
69e9e779 |
| 11-Jun-2024 |
Pavel Samolysov <samolisov@gmail.com> |
[clang] Replace X && isa<Y>(X) with isa_and_nonnull<Y>(X). NFC (#94987)
This addresses a clang-tidy suggestion.
|
Revision tags: llvmorg-18.1.7 |
|
#
3575d23c |
| 20-May-2024 |
Ahmed Bougacha <ahmed@bougacha.org> |
[clang][CodeGen] Remove unused LValue::getAddress CGF arg. (#92465)
This is in effect a revert of f139ae3d93797, as we have since gained a
more sophisticated way of doing extra IRGen with the addit
[clang][CodeGen] Remove unused LValue::getAddress CGF arg. (#92465)
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.
show more ...
|
Revision tags: llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4 |
|
#
fca51911 |
| 11-Apr-2024 |
Bill Wendling <5993918+bwendling@users.noreply.github.com> |
[NFC][Clang] Improve const correctness for IdentifierInfo (#79365)
The IdentifierInfo isn't typically modified. Use 'const' wherever
possible.
|
#
417a068b |
| 04-Apr-2024 |
Mikael Holmen <mikael.holmen@ericsson.com> |
[clang][CGBlocks] Remove unused variable "refType" [NFC]
Without the change gcc warned like ../../clang/lib/CodeGen/CGBlocks.cpp:965:21: warning: unused variable 'refType' [-Wunused-variable] 96
[clang][CGBlocks] Remove unused variable "refType" [NFC]
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>()) { | ^~~~~~~
show more ...
|
Revision tags: llvmorg-18.1.3 |
|
#
84780af4 |
| 28-Mar-2024 |
Akira Hatanaka <ahatanak@gmail.com> |
[CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (#86923)
To authenticate pointers, CodeGen needs access to the key and
discriminators tha
[CodeGen][arm64e] Add methods and data members to Address, which are needed 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).
show more ...
|
#
f75eebab |
| 28-Mar-2024 |
Akira Hatanaka <ahatanak@gmail.com> |
Revert "[CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (#86721)" (#86898)
This reverts commit d9a685a9dd589486e882b722e513ee7b8c84870c.
Revert "[CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (#86721)" (#86898)
This reverts commit d9a685a9dd589486e882b722e513ee7b8c84870c.
The commit broke ubsan bots.
show more ...
|
#
d9a685a9 |
| 27-Mar-2024 |
Akira Hatanaka <ahatanak@gmail.com> |
[CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (#86721)
To authenticate pointers, CodeGen needs access to the key and
discriminators th
[CodeGen][arm64e] Add methods and data members to Address, which are needed 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.
show more ...
|
#
b3117564 |
| 26-Mar-2024 |
Akira Hatanaka <ahatanak@gmail.com> |
Revert "[CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (#67454)" (#86674)
This reverts commit 8bd1f9116aab879183f34707e6d21c7051d083b6.
Revert "[CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (#67454)" (#86674)
This reverts commit 8bd1f9116aab879183f34707e6d21c7051d083b6.
It appears that the commit broke msan bots.
show more ...
|
#
8bd1f911 |
| 26-Mar-2024 |
Akira Hatanaka <ahatanak@gmail.com> |
[CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (#67454)
To authenticate pointers, CodeGen needs access to the key and
discriminators tha
[CodeGen][arm64e] Add methods and data members to Address, which are needed 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.
show more ...
|
Revision tags: llvmorg-18.1.2 |
|
#
3e6db602 |
| 18-Mar-2024 |
Orlando Cazalet-Hyams <orlando.hyams@sony.com> |
[RemoveDIs] Update Clang front end to handle DbgRecords (#84756)
This patch fixes problems that pop up when clang emits DbgRecords instead of debug intrinsics.
Note: this doesn't mean clang is emit
[RemoveDIs] Update Clang front end to handle DbgRecords (#84756)
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
show more ...
|
#
92122b0b |
| 18-Mar-2024 |
Orlando Cazalet-Hyams <orlando.hyams@sony.com> |
Revert "[RemoveDIs] Update Clang front end to handle DbgRecords (#84756)"
This reverts commit 6f60ad7e9a3508f19d54c827cf11f7930a0685ee.
Buildbots: https://lab.llvm.org/buildbot/#/builders/196/build
Revert "[RemoveDIs] Update Clang front end to handle DbgRecords (#84756)"
This reverts commit 6f60ad7e9a3508f19d54c827cf11f7930a0685ee.
Buildbots: https://lab.llvm.org/buildbot/#/builders/196/builds/47206
show more ...
|
#
3e4170a5 |
| 18-Mar-2024 |
Orlando Cazalet-Hyams <orlando.hyams@sony.com> |
Revert "Fix formatting in #84756"
This reverts commit b097b3dc2ba2517621a5e3da3237a77ed0e7586f.
Buildbots: https://lab.llvm.org/buildbot/#/builders/196/builds/47206
|
#
b097b3dc |
| 18-Mar-2024 |
Orlando Cazalet-Hyams <orlando.hyams@sony.com> |
Fix formatting in #84756
|
#
6f60ad7e |
| 18-Mar-2024 |
Orlando Cazalet-Hyams <orlando.hyams@sony.com> |
[RemoveDIs] Update Clang front end to handle DbgRecords (#84756)
This patch fixes problems that pop up when clang emits DbgRecords
instead of debug intrinsics.
Note: this doesn't mean clang is e
[RemoveDIs] Update Clang front end to handle DbgRecords (#84756)
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
show more ...
|
Revision tags: llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5 |
|
#
dda8e3de |
| 06-Nov-2023 |
Vlad Serebrennikov <serebrennikov.vladislav@gmail.com> |
[clang][NFC] Refactor `ImplicitParamDecl::ImplicitParamKind`
This patch converts `ImplicitParamDecl::ImplicitParamKind` into a scoped enum at namespace scope, making it eligible for forward declarin
[clang][NFC] Refactor `ImplicitParamDecl::ImplicitParamKind`
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.
show more ...
|
#
5532d67a |
| 02-Nov-2023 |
Youngsuk Kim <youngsuk.kim@hpe.com> |
[clang] Remove no-op ptr-to-ptr bitcasts (NFC)
Opaque ptr cleanup effort (NFC)
|
#
09f1aaca |
| 01-Nov-2023 |
Youngsuk Kim <youngsuk.kim@hpe.com> |
[CGBlocks] Remove no-op ptr-to-ptr bitcasts (NFC)
Opaque ptr cleanup effort. NFC.
|