Reapply "[clang] Avoid re-evaluating field bitwidth" (#122289)

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 ...

[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 ...

[CodeGen] Remove unused includes (NFC) (#116459)

Identified with misc-include-cleaner.

[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 ...

SwiftCallingConv: Fix the splitVectorEntry function (#69953)

When splitting an entry into multiple entries, the indices of the split
entries are a combination of the original split entry's and the

SwiftCallingConv: Fix the splitVectorEntry function (#69953)

When splitting an entry into multiple entries, the indices of the split
entries are a combination of the original split entry's and the number
of elements we split that entry to.

Failure to do so resulted in non-sensical entries leading e.g to
assertion failures in `getCoerceAndExpandTypes` and runtime failures in
Swift programs.

show more ...

Use llvm::Log2_32 and llvm::Log2_64 instead of llvm::findLastSet (NFC)

For a nonzero argument, llvm::findLastSet(x) is equivalent to
llvm::Log2_32(x) or llvm::Log2_64(x). None of the calls to
llvm:

Use llvm::Log2_32 and llvm::Log2_64 instead of llvm::findLastSet (NFC)

For a nonzero argument, llvm::findLastSet(x) is equivalent to
llvm::Log2_32(x) or llvm::Log2_64(x). None of the calls to
llvm::findLastSet in this patch relies on llvm::findLastSet's ability
to return std::numeric_limits<T>::max() on input 0.

show more ...

[CodeGen] Use llvm::bit_ceil (NFC)

If we know that x is nonzero and not a power of 2, then
llvm::findLastSet(x) + 1 is the index of the bit just above the
highest set bit in x. That is, 1 << (llvm:

[CodeGen] Use llvm::bit_ceil (NFC)

If we know that x is nonzero and not a power of 2, then
llvm::findLastSet(x) + 1 is the index of the bit just above the
highest set bit in x. That is, 1 << (llvm::findLastSet(x) + 1) is the
same as llvm::bit_ceil(x).

Since llvm::bit_ceil is a nop on a power of 2, we can unconditionally
call llvm::bit_ceil. The end result actually matches the comment.

show more ...

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is p

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Option

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[clang][NFC] Remove dependency on DataLayout::getPrefTypeAlignment

[clang][TargetInfo] Use LangAS for getPointer{Width,Align}()

Mixing LLVM and Clang address spaces can result in subtle bugs, and there
is no need for this hook to use the LLVM IR level address space

[clang][TargetInfo] Use LangAS for getPointer{Width,Align}()

Mixing LLVM and Clang address spaces can result in subtle bugs, and there
is no need for this hook to use the LLVM IR level address spaces.
Most of this change is just replacing zero with LangAS::Default,
but it also allows us to remove a few calls to getTargetAddressSpace().

This also removes a stale comment+workaround in
CGDebugInfo::CreatePointerLikeType(): ASTContext::getTypeSize() does
return the expected size for ReferenceType (and handles address spaces).

Differential Revision: https://reviews.llvm.org/D138295

show more ...

[clang] Qualify auto in range-based for loops (NFC)

[clang][CodeGen] Factor out Swift ABI hooks (NFCI)

Swift calling conventions stands out in the way that they are lowered in
mostly target-independent manner, with very few customization points.
As s

[clang][CodeGen] Factor out Swift ABI hooks (NFCI)

Swift calling conventions stands out in the way that they are lowered in
mostly target-independent manner, with very few customization points.
As such, swift-related methods of ABIInfo do not reference the rest of
ABIInfo and vice versa.
This change follows interface segregation principle; it removes
dependency of SwiftABIInfo on ABIInfo. Targets must now implement
SwiftABIInfo separately if they support Swift calling conventions.

Almost all targets implemented `shouldPassIndirectly` the same way. This
de-facto default implementation has been moved into the base class.

`isSwiftErrorInRegister` used to be virtual, now it is not. It didn't
accept any arguments which could have an effect on the returned value.
This is now a static property of the target ABI.

Reviewed By: rusyaev-roman, inclyc

Differential Revision: https://reviews.llvm.org/D130394

show more ...

[clang][CodeGen] Only include ABIInfo.h where required (NFC)

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D130322

Teach the swift calling convention about _Atomic types

rdar://67351073

Differential Revision: https://reviews.llvm.org/D86218

[SVE] Remove calls to VectorType::getNumElements from clang

Reviewed By: RKSimon

Differential Revision: https://reviews.llvm.org/D82582

[SVE] Eliminate calls to default-false VectorType::get() from Clang

Reviewers: efriedma, david-arm, fpetrogalli, ddunbar, rjmccall

Reviewed By: fpetrogalli, rjmccall

Subscribers: tschuett, rkruppe

[SVE] Eliminate calls to default-false VectorType::get() from Clang

Reviewers: efriedma, david-arm, fpetrogalli, ddunbar, rjmccall

Reviewed By: fpetrogalli, rjmccall

Subscribers: tschuett, rkruppe, psnobl, dmgreen, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D80323

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

In swiftcall, don't merge FP/vector types within a chunk.

llvm-svn: 345536

Remove trailing space

sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}

llvm-svn: 338291

Generalize the swiftcall API since being passed indirectly isn't
C++-specific anymore.

llvm-svn: 329513

Fix a major swiftcall ABI bug with trivial C++ class types.

The problem with the previous logic was that there might not be any
explicit copy/move constructor declarations, e.g. if the type is
trivi

Fix a major swiftcall ABI bug with trivial C++ class types.

The problem with the previous logic was that there might not be any
explicit copy/move constructor declarations, e.g. if the type is
trivial and we've never type-checked a copy of it. Relying on Sema's
computation seems much more reliable.

Also, I believe Richard's recommendation is exactly the rule we use
now on the Itanium ABI, modulo the trivial_abi attribute (which this
change of course fixes our handling of in Swift).

This does mean that we have a less portable rule for deciding
indirectness for swiftcall. I would prefer it if we just applied the
Itanium rule universally under swiftcall, but in the meantime, I need
to fix this bug.

This only arises when defining functions with class-type arguments
in C++, as we do in the Swift runtime. It doesn't affect normal Swift
operation because we don't import code as C++.

llvm-svn: 328942

show more ...

Simplify the internal API for checking whether swiftcall passes a type indirectly and expose that API externally.

llvm-svn: 321957

SwiftCC: Perform physical layout when computing coercion types

We need to take type alignment padding into account whe computing physical
layouts.

The layout must be compatible with the input layou

SwiftCC: Perform physical layout when computing coercion types

We need to take type alignment padding into account whe computing physical
layouts.

The layout must be compatible with the input layout, offsets are defined in
terms of offsets within a packed struct which are computed in terms of the alloc
size of a type.

Usingthe store size we would insert padding for the following type for example:

struct {

int3 v;
long long l;
} __attribute((packed))

On x86-64 int3 is padded to int4 alignment. The swiftcc type would be
<{ <3 x float>, [4 x i8], i64 }> which is not compatible with <{ <3 x float>,
i64 }>.

The latter has i64 at offset 16 and the former at offset 20.

rdar://32618125

llvm-svn: 305956

show more ...