Revision tags: llvmorg-21-init, llvmorg-19.1.7 |
|
#
cfe26358 |
| 11-Jan-2025 |
Timm Baeder <tbaeder@redhat.com> |
Reapply "[clang] Avoid re-evaluating field bitwidth" (#122289)
|
#
59bdea24 |
| 08-Jan-2025 |
Timm Bäder <tbaeder@redhat.com> |
Revert "[clang] Avoid re-evaluating field bitwidth (#117732)"
This reverts commit 81fc3add1e627c23b7270fe2739cdacc09063e54.
This breaks some LLDB tests, e.g. SymbolFile/DWARF/x86/no_unique_address-
Revert "[clang] Avoid re-evaluating field bitwidth (#117732)"
This reverts commit 81fc3add1e627c23b7270fe2739cdacc09063e54.
This breaks some LLDB tests, e.g. SymbolFile/DWARF/x86/no_unique_address-with-bitfields.cpp:
lldb: ../llvm-project/clang/lib/AST/Decl.cpp:4604: unsigned int clang::FieldDecl::getBitWidthValue() const: Assertion `isa<ConstantExpr>(getBitWidth())' failed.
show more ...
|
#
81fc3add |
| 08-Jan-2025 |
Timm Baeder <tbaeder@redhat.com> |
[clang] Avoid re-evaluating field bitwidth (#117732)
Save the bitwidth value as a `ConstantExpr` with the value set. Remove the `ASTContext` parameter from `getBitWidthValue()`, so the latter simply
[clang] Avoid re-evaluating field bitwidth (#117732)
Save the bitwidth value as a `ConstantExpr` with the value set. Remove the `ASTContext` parameter from `getBitWidthValue()`, so the latter simply returns the value from the `ConstantExpr` instead of constant-evaluating the bitwidth expression every time it is called.
show more ...
|
Revision tags: llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3 |
|
#
af7c58b7 |
| 28-Oct-2024 |
Aaron Ballman <aaron@aaronballman.com> |
Remove support for RenderScript (#112916)
See
https://discourse.llvm.org/t/rfc-deprecate-and-eventually-remove-renderscript-support/81284
for the RFC
|
Revision tags: llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3 |
|
#
f95026db |
| 19-Aug-2024 |
Lei Huang <lei@ca.ibm.com> |
[PowerPC] Fix codegen for transparent_union function params (#101738)
Update codegen for func param with transparent_union attr to be that of
the first union member.
PPC fix for: https://github.
[PowerPC] Fix codegen for transparent_union function params (#101738)
Update codegen for func param with transparent_union attr to be that of
the first union member.
PPC fix for: https://github.com/llvm/llvm-project/issues/76773
show more ...
|
Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
4497ec29 |
| 16-Jul-2024 |
Michael Buch <michaelbuch12@gmail.com> |
[clang][CGRecordLayout] Remove dependency on isZeroSize (#96422)
This is a follow-up from the conversation starting at
https://github.com/llvm/llvm-project/pull/93809#issuecomment-2173729801
The
[clang][CGRecordLayout] Remove dependency on isZeroSize (#96422)
This is a follow-up from the conversation starting at
https://github.com/llvm/llvm-project/pull/93809#issuecomment-2173729801
The root problem that motivated the change are external AST sources that
compute `ASTRecordLayout`s themselves instead of letting Clang compute
them from the AST. One such example is LLDB using DWARF to get the
definitive offsets and sizes of C++ structures. Such layouts should be
considered correct (modulo buggy DWARF), but various assertions and
lowering logic around the `CGRecordLayoutBuilder` relies on the AST
having `[[no_unique_address]]` attached to them. This is a
layout-altering attribute which is not encoded in DWARF. This causes us
LLDB to trip over the various LLVM<->Clang layout consistency checks.
There has been precedent for avoiding such layout-altering attributes
from affecting lowering with externally-provided layouts (e.g., packed
structs).
This patch proposes to replace the `isZeroSize` checks in
`CGRecordLayoutBuilder` (which roughly means "empty field with
[[no_unique_address]]") with checks for
`CodeGen::isEmptyField`/`CodeGen::isEmptyRecord`.
**Details**
The main strategy here was to change the `isZeroSize` check in
`CGRecordLowering::accumulateFields` and
`CGRecordLowering::accumulateBases` to use the `isEmptyXXX` APIs
instead, preventing empty fields from being added to the `Members` and
`Bases` structures. The rest of the changes fall out from here, to
prevent lookups into these structures (for field numbers or base
indices) from failing.
Added `isEmptyRecordForLayout` and `isEmptyFieldForLayout` (open to
better naming suggestions). The main difference to the existing
`isEmptyRecord`/`isEmptyField` APIs, is that the `isEmptyXXXForLayout`
counterparts don't have special treatment for `unnamed bitfields`/arrays
and also treat fields of empty types as if they had
`[[no_unique_address]]` (i.e., just like the `AsIfNoUniqueAddr` in
`isEmptyField` does).
show more ...
|
#
6d973b45 |
| 17-Jun-2024 |
Mariya Podchishchaeva <mariya.podchishchaeva@intel.com> |
[clang][CodeGen] Return RValue from `EmitVAArg` (#94635)
This should simplify handling of resulting value by the callers.
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5 |
|
#
78eb2c2c |
| 18-Apr-2024 |
Jon Chesterfield <jonathanchesterfield@gmail.com> |
[clang] Preserve argument type in round pointer to alignment
|
#
3d56ea05 |
| 18-Apr-2024 |
Timm Baeder <tbaeder@redhat.com> |
[clang][NFC] Fix FieldDecl::isUnnamedBitfield() capitalization (#89048)
We always capitalize bitfield as "BitField".
|
Revision tags: llvmorg-18.1.4, 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 ...
|
#
28ddbd4a |
| 26-Mar-2024 |
Chris B <chris.bieneman@me.com> |
[NFC] Refactor ConstantArrayType size storage (#85716)
In PR #79382, I need to add a new type that derives from
ConstantArrayType. This means that ConstantArrayType can no longer use
`llvm::Traili
[NFC] Refactor ConstantArrayType size storage (#85716)
In PR #79382, I need to add a new type that derives from
ConstantArrayType. This means that ConstantArrayType can no longer use
`llvm::TrailingObjects` to store the trailing optional Expr*.
This change refactors ConstantArrayType to store a 60-bit integer and
4-bits for the integer size in bytes. This replaces the APInt field
previously in the type but preserves enough information to recreate it
where needed.
To reduce the number of places where the APInt is re-constructed I've
also added some helper methods to the ConstantArrayType to allow some
common use cases that operate on either the stored small integer or the
APInt as appropriate.
Resolves #85124.
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, 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, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2 |
|
#
e3c57fdd |
| 07-Aug-2023 |
Alex Bradbury <asb@igalia.com> |
[clang][RISCV] Fix bug in ABI handling of empty structs with hard FP calling conventions in C++
As reported in <https://github.com/llvm/llvm-project/issues/58929>, Clang's handling of empty structs
[clang][RISCV] Fix bug in ABI handling of empty structs with hard FP calling conventions in C++
As reported in <https://github.com/llvm/llvm-project/issues/58929>, Clang's handling of empty structs in the case of small structs that may be eligible to be passed using the hard FP calling convention doesn't match g++. In general, C++ record fields are never empty unless [[no_unique_address]] is used, but the RISC-V FP ABI overrides this.
After this patch, fields of structs that contain empty records will be ignored, even in C++, when considering eligibility for the FP calling convention ('flattening'). It isn't explicitly noted in the RISC-V psABI, but arrays of empty records will disqualify a struct for consideration of using the FP calling convention in g++. This patch matches that behaviour. The psABI issue <https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/358> seeks to clarify this.
This patch was previously committed but reverted after a bug was found. This recommit adds additional logic to prevent that bug (adding an extra check for when a candidate from detectFPCCEligibleStructHelper may not be valid).
Differential Revision: https://reviews.llvm.org/D142327
show more ...
|
Revision tags: llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
0fa004e0 |
| 24-Jul-2023 |
Alex Bradbury <asb@igalia.com> |
Revert "[clang][RISCV] Fix ABI handling of empty structs with hard FP calling conventions in C++"
This reverts commit 17a58b3ca7ec18585e9ea8ed8b39d72fe36fb6cb and the minor documentation fix 569e99a
Revert "[clang][RISCV] Fix ABI handling of empty structs with hard FP calling conventions in C++"
This reverts commit 17a58b3ca7ec18585e9ea8ed8b39d72fe36fb6cb and the minor documentation fix 569e99a471f618b7fdf045d5e96f21d3e3a7f898.
An issue was reported in https://reviews.llvm.org/D142327#inline-1510301 so reverting until it can be investigated and fixed.
show more ...
|
#
17a58b3c |
| 24-Jul-2023 |
Alex Bradbury <asb@igalia.com> |
[clang][RISCV] Fix ABI handling of empty structs with hard FP calling conventions in C++
As reported in <https://github.com/llvm/llvm-project/issues/58929>, Clang's handling of empty structs in the
[clang][RISCV] Fix ABI handling of empty structs with hard FP calling conventions in C++
As reported in <https://github.com/llvm/llvm-project/issues/58929>, Clang's handling of empty structs in the case of small structs that may be eligible to be passed using the hard FP calling convention doesn't match g++. In general, C++ record fields are never empty unless [[no_unique_address]] is used, but the RISC-V FP ABI overrides this.
After this patch, fields of structs that contain empty records will be ignored, even in C++, when considering eligibility for the FP calling convention ('flattening'). See also the relevant psABI issue <https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/358> which seeks to clarify the documentation.
Fixes https://github.com/llvm/llvm-project/issues/58929
Differential Revision: https://reviews.llvm.org/D142327
show more ...
|
#
5f32baf1 |
| 30-Jun-2023 |
Youngsuk Kim <youngsuk.kim@hpe.com> |
[clang] Replace uses of CreateElementBitCast (NFC)
Partial progress towards replacing uses of CreateElementBitCast, as it no longer does what its name suggests.
Reviewed By: barannikov88
Different
[clang] Replace uses of CreateElementBitCast (NFC)
Partial progress towards replacing uses of CreateElementBitCast, as it no longer does what its name suggests.
Reviewed By: barannikov88
Differential Revision: https://reviews.llvm.org/D154229
show more ...
|
Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4 |
|
#
992cb984 |
| 09-May-2023 |
Sergei Barannikov <barannikov88@gmail.com> |
[clang][CodeGen] Break up TargetInfo.cpp [8/8]
This commit breaks up CodeGen/TargetInfo.cpp into a set of *.cpp files, one file per target. There are no functional changes, mostly just code moving.
[clang][CodeGen] Break up TargetInfo.cpp [8/8]
This commit breaks up CodeGen/TargetInfo.cpp into a set of *.cpp files, one file per target. There are no functional changes, mostly just code moving.
Non-code-moving changes are: * A virtual destructor has been added to DefaultABIInfo to pin the vtable to a cpp file. * A few methods of ABIInfo and DefaultABIInfo were split into declaration + definition in order to reduce the number of transitive includes. * Several functions that used to be static have been placed in clang::CodeGen namespace so that they can be accessed from other cpp files.
RFC: https://discourse.llvm.org/t/rfc-splitting-clangs-targetinfo-cpp/69883
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D148094
show more ...
|