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

swiftcc: Add an api to query whether a target ABI stores swifterror in a register

llvm-svn: 288394

Swift Calling Convention: Fix out of bounds access

Use iterator instead of address of element in vector

It is not valid to access one after the last element.

rdar://28759508

llvm-svn: 284150

Pass the end of a component to SwiftAggLowering's enumerateComponents callback

This is usefull for determining whether components overlap.

llvm-svn: 283932

Silencing a 32-bit shift implicit conversion warning from MSVC; NFC.

llvm-svn: 265782

Fix "suggest parentheses" warning.

llvm-svn: 265355

Fix an unused-variable warning by using the variable in the place
it was supposed to have been used.

llvm-svn: 265344

IRGen-level lowering for the Swift calling convention.

llvm-svn: 265324