[clang-repl] [codegen] Reduce the state in TBAA. NFC for static compilation. (#98138)

In incremental compilation clang works with multiple `llvm::Module`s.
Our current approach is to create a CodeG

[clang-repl] [codegen] Reduce the state in TBAA. NFC for static compilation. (#98138)

In incremental compilation clang works with multiple `llvm::Module`s.
Our current approach is to create a CodeGenModule entity for every new
module request (via StartModule). However, some of the state such as the
mangle context needs to be preserved to keep the original semantics in
the ever-growing TU.

Fixes: llvm/llvm-project#95581.

cc: @jeaye

show more ...

[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364)

There are two problems with _BitInt prior to this patch:
1. For at least some values of N, we cannot use LLVM's iN for th

[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364)

There are two problems with _BitInt prior to this patch:
1. For at least some values of N, we cannot use LLVM's iN for the type
of struct elements, array elements, allocas, global variables, and so
on, because the LLVM layout for that type does not match the high-level
layout of _BitInt(N).
Example: Currently for i128:128 targets correct implementation is
possible either for __int128 or for _BitInt(129+) with lowering to iN,
but not both, since we have now correct implementation of __int128 in
place after a21abc7.
When this happens, opaque [M x i8] types used, where M =
sizeof(_BitInt(N)).
2. LLVM doesn't guarantee any particular extension behavior for integer
types that aren't a multiple of 8. For this reason, all _BitInt types
are now have in-memory representation that is a whole number of bytes.
I.e. for example _BitInt(17) now will have memory layout type i32.

This patch also introduces concept of load/store type and adds an API to
CodeGenTypes that returns the IR type that should be used for load and
store operations. This is particularly useful for the case when a
_BitInt ends up having array of bytes as memory layout type. For
_BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and
stores of iM would both (1) produce far better code from the backends
and (2) be far more optimizable by IR passes than loads and stores of [M
x i8].

Fixes https://github.com/llvm/llvm-project/issues/85139
Fixes https://github.com/llvm/llvm-project/issues/83419

---------

Co-authored-by: John McCall <rjmccall@gmail.com>

show more ...

[PowerPC] Emit IR module flag for current float abi

This is part of the efforts adding .gnu_attribute support for PowerPC.
In Clang, an extra metadata field will be added as float-abi to show
curren

[PowerPC] Emit IR module flag for current float abi

This is part of the efforts adding .gnu_attribute support for PowerPC.
In Clang, an extra metadata field will be added as float-abi to show
current long double format. So backend can emit .gnu_attribute section
data from this metadata.

To avoid breaking existing behavior, the module metadata will only be
emitted when this module makes use of long double.

Reviewed By: nemanjai

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

show more ...

Reland "Try to implement lambdas with inalloca parameters by forwarding without use of inallocas."t

This reverts commit 8ed7aa59f489715d39d32e72a787b8e75cfda151.

Differential Revision: https://revi

Reland "Try to implement lambdas with inalloca parameters by forwarding without use of inallocas."t

This reverts commit 8ed7aa59f489715d39d32e72a787b8e75cfda151.

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

show more ...

Revert "Try to implement lambdas with inalloca parameters by forwarding without use of inallocas."

Causes a clang crash (see crbug.com/1457256).

This reverts commit 015049338d7e8e0e81f2ad2f94e5a43e

Revert "Try to implement lambdas with inalloca parameters by forwarding without use of inallocas."

Causes a clang crash (see crbug.com/1457256).

This reverts commit 015049338d7e8e0e81f2ad2f94e5a43e2e3f5220.

show more ...

Try to implement lambdas with inalloca parameters by forwarding without use of inallocas.

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

[CGTypes] Remove recursion protection

With opaque pointers, it should no longer be necessary to protect
against recursion when converting Clang types to LLVM types, as
recursion can only be introduc

[CGTypes] Remove recursion protection

With opaque pointers, it should no longer be necessary to protect
against recursion when converting Clang types to LLVM types, as
recursion can only be introduced via pointer types.

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

show more ...

[SystemZ] Emit a .gnu_attribute for an externally visible vector abi.

On SystemZ, the vector ABI changes depending on the presence of hardware
vector support. Therefore, each binary compiled with a

[SystemZ] Emit a .gnu_attribute for an externally visible vector abi.

On SystemZ, the vector ABI changes depending on the presence of hardware
vector support. Therefore, each binary compiled with a visible vector ABI
(e.g. one that calls an external function with a vector argument) should be
marked with a .gnu_attribute describing this.

Reviewed By: uweigand

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

show more ...

[clang] Avoid duplicating ProgramAddressSpace in TargetInfo. NFCI

This value was added to clang/Basic in D111566, but is only used during
codegen, where we can use the LLVM IR DataLayout instead. I

[clang] Avoid duplicating ProgramAddressSpace in TargetInfo. NFCI

This value was added to clang/Basic in D111566, but is only used during
codegen, where we can use the LLVM IR DataLayout instead. I noticed this
because the downstream CHERI targets would have to also set this value
for AArch64/RISC-V/MIPS. Instead of duplicating more information between
LLVM IR and Clang, this patch moves getTargetAddressSpace(QualType T) to
CodeGenTypes, where we can consult the DataLayout.

Reviewed By: rjmccall

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

show more ...

[clang] Properly cache member pointer LLVM types

When not going through the main Clang->LLVM type cache, we'd
accidentally create multiple different opaque types for a member pointer
type.

This all

[clang] Properly cache member pointer LLVM types

When not going through the main Clang->LLVM type cache, we'd
accidentally create multiple different opaque types for a member pointer
type.

This allows us to remove the -verify-type-cache flag now that
check-clang passes with it on. We can do the verification in expensive
builds. Previously microsoft-abi-member-pointers.cpp was failing with
-verify-type-cache.

I suspect that there may be more issues when we have multiple member
pointer types and we clear the cache, but we can leave that for later.

Followup to D118744.

Reviewed By: rnk

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

show more ...

[NFC] Increase initial size of FoldingSets used in ASTContext and CodeGenTypes

Among many FoldingSet users most notable seem to be ASTContext and CodeGenTypes.
The reasons that we spend not-so-tiny

[NFC] Increase initial size of FoldingSets used in ASTContext and CodeGenTypes

Among many FoldingSet users most notable seem to be ASTContext and CodeGenTypes.
The reasons that we spend not-so-tiny amount of time in FoldingSet calls from there, are following:

1. Default FoldingSet capacity for 2^6 items very often is not enough.
For PointerTypes/ElaboratedTypes/ParenTypes it's not unlikely to observe growing it to 256 or 512 items.
FunctionProtoTypes can easily exceed 1k items capacity growing up to 4k or even 8k size.

2. FoldingSetBase::GrowBucketCount cost itself is not very bad (pure reallocations are rather cheap thanks to BumpPtrAllocator).
What matters is high collision rate when lot of items end up in same bucket slowing down FoldingSetBase::FindNodeOrInsertPos and trashing CPU cache
(as items with same hash are organized in intrusive linked list which need to be traversed).

This change address both issues by increasing initial size of FoldingSets used in ASTContext and CodeGenTypes.

Extracted from: https://reviews.llvm.org/D118385

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

show more ...

[clang] Remove unused forward declarations (NFC)

CodeGenTypes::CGRecordLayouts: Use unique_ptr to simplify memory management

Reland Implement _ExtInt as an extended int type specifier.

I fixed the LLDB issue, so re-applying the patch.

This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.

Revert "Implement _ExtInt as an extended int type specifier."

This reverts commit 61ba1481e200b5b35baa81ffcff81acb678e8508.

I'm reverting this because it breaks the lldb build with
incomplete switc

Revert "Implement _ExtInt as an extended int type specifier."

This reverts commit 61ba1481e200b5b35baa81ffcff81acb678e8508.

I'm reverting this because it breaks the lldb build with
incomplete switch coverage warnings. I would fix it forward,
but am not familiar enough with lldb to determine the correct
fix.

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:3958:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch]
switch (qual_type->getTypeClass()) {
^
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4633:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch]
switch (qual_type->getTypeClass()) {
^
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4889:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch]
switch (qual_type->getTypeClass()) {

show more ...

Implement _ExtInt as an extended int type specifier.

Introduction/Motivation:
LLVM-IR supports integers of non-power-of-2 bitwidth, in the iN syntax.
Integers of non-power-of-two aren't particularly

Implement _ExtInt as an extended int type specifier.

Introduction/Motivation:
LLVM-IR supports integers of non-power-of-2 bitwidth, in the iN syntax.
Integers of non-power-of-two aren't particularly interesting or useful
on most hardware, so much so that no language in Clang has been
motivated to expose it before.

However, in the case of FPGA hardware normal integer types where the
full bitwidth isn't used, is extremely wasteful and has severe
performance/space concerns. Because of this, Intel has introduced this
functionality in the High Level Synthesis compiler[0]
under the name "Arbitrary Precision Integer" (ap_int for short). This
has been extremely useful and effective for our users, permitting them
to optimize their storage and operation space on an architecture where
both can be extremely expensive.

We are proposing upstreaming a more palatable version of this to the
community, in the form of this proposal and accompanying patch. We are
proposing the syntax _ExtInt(N). We intend to propose this to the WG14
committee[1], and the underscore-capital seems like the active direction
for a WG14 paper's acceptance. An alternative that Richard Smith
suggested on the initial review was __int(N), however we believe that
is much less acceptable by WG14. We considered _Int, however _Int is
used as an identifier in libstdc++ and there is no good way to fall
back to an identifier (since _Int(5) is indistinguishable from an
unnamed initializer of a template type named _Int).

[0]https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html)
[1]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf

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

show more ...

IRGen: Remove StructorType; thread GlobalDecl through more code. NFCI.

This should make it easier to add more structor variants.

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

llvm-svn: 35

IRGen: Remove StructorType; thread GlobalDecl through more code. NFCI.

This should make it easier to add more structor variants.

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

llvm-svn: 356822

show more ...

[opaque pointer types] Fix the CallInfo passed to EmitCall in some
edge cases.

Currently, EmitCall emits a call instruction with a function type
derived from the pointee-type of the callee. This *sh

[opaque pointer types] Fix the CallInfo passed to EmitCall in some
edge cases.

Currently, EmitCall emits a call instruction with a function type
derived from the pointee-type of the callee. This *should* be the same
as the type created from the CallInfo parameter, but in some cases an
incorrect CallInfo was being passed.

All of these fixes were discovered by the addition of the assert in
EmitCall which verifies that the passed-in CallInfo matches the
Callee's function type.

As far as I know, these issues caused no bugs at the moment, as the
correct types were ultimately being emitted. But, some would become
problematic when pointee types are removed.

List of fixes:

* arrangeCXXConstructorCall was passing an incorrect value for the
number of Required args, when calling an inheriting constructor
where the inherited constructor is variadic. (The inheriting
constructor doesn't actually get passed any of the user's args, but
the code was calculating it as if it did).

* arrangeFreeFunctionLikeCall was not including the count of the
pass_object_size arguments in the count of required args.

* OpenCL uses other address spaces for the "this" pointer. However,
commonEmitCXXMemberOrOperatorCall was not annotating the address
space on the "this" argument of the call.

* Destructor calls were being created with EmitCXXMemberOrOperatorCall
instead of EmitCXXDestructorCall in a few places. This was a problem
because the calling convention sometimes has destructors returning
"this" rather than void, and the latter function knows about that,
and sets up the types properly (through calling
arrangeCXXStructorDeclaration), while the former does not.

* generateObjCGetterBody: the 'objc_getProperty' function returns type
'id', but was being called as if it returned the particular
property's type. (That is of course the *dynamic* return type, and
there's a downcast immediately after.)

* OpenMP user-defined reduction functions (#pragma omp declare
reduction) can be called with a subclass of the declared type. In
such case, the call was being setup as if the function had been
actually declared to take the subtype, rather than the base type.

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

llvm-svn: 353181

show more ...

Remove redundant FunctionDecl argument from a couple functions.

This argument was added in r254554 in order to support the
pass_object_size attribute. However, in r296076, the attribute's
presence i

Remove redundant FunctionDecl argument from a couple functions.

This argument was added in r254554 in order to support the
pass_object_size attribute. However, in r296076, the attribute's
presence is now also represented in FunctionProtoType's
ExtParameterInfo, and thus it's unnecessary to pass along a separate
FunctionDecl.

The functions modified are:
RequiredArgs::forPrototype{,Plus}, and
CodeGenTypes::ConvertFunctionType.

After this, it's also (again) unnecessary to have a separate
ConvertFunctionType function ConvertType, so convert callers back to
the latter, leaving the former as an internal helper function.

llvm-svn: 352946

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

Remove unnecessary include.

llvm-svn: 348238

Remove trailing space

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

llvm-svn: 338291

Remove \brief commands from doxygen comments.

This is similar to the LLVM change https://reviews.llvm.org/D46290.

We've been running doxygen with the autobrief option for a couple of
years now. Thi

Remove \brief commands from doxygen comments.

This is similar to the LLVM change https://reviews.llvm.org/D46290.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

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

llvm-svn: 331834

show more ...

[MS] Emit vftable thunks for functions with incomplete prototypes

Summary:
The following class hierarchy requires that we be able to emit a
this-adjusting thunk for B::foo in C's vftable:

struct

[MS] Emit vftable thunks for functions with incomplete prototypes

Summary:
The following class hierarchy requires that we be able to emit a
this-adjusting thunk for B::foo in C's vftable:

struct Incomplete;
struct A {
virtual A* foo(Incomplete p) = 0;
};
struct B : virtual A {
void foo(Incomplete p) override;
};
struct C : B { int c; };

This TU is valid, but lacks a definition of 'Incomplete', which makes it
hard to build a thunk for the final overrider, B::foo.

Before this change, Clang gives up attempting to emit the thunk, because
it assumes that if the parameter types are incomplete, it must be
emitting the thunk for optimization purposes. This is untrue for the MS
ABI, where the implementation of B::foo has no idea what thunks C's
vftable may require. Clang needs to emit the thunk without necessarily
having access to the complete prototype of foo.

This change makes Clang emit a musttail variadic call when it needs such
a thunk. I call these "unprototyped" thunks, because they only prototype
the "this" parameter, which must always come first in the MS C++ ABI.

These thunks work, but they create ugly LLVM IR. If the call to the
thunk is devirtualized, it will be a call to a bitcast of a function
pointer. Today, LLVM cannot inline through such a call, but I want to
address that soon, because we also use this pattern for virtual member
pointer thunks.

This change also implements an old FIXME in the code about reusing the
thunk's computed CGFunctionInfo as much as possible. Now we don't end up
computing the thunk's mangled name and arranging it's prototype up to
around three times.

Fixes PR25641

Reviewers: rjmccall, rsmith, hans

Subscribers: Prazek, cfe-commits

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

llvm-svn: 329009

show more ...

[OpenCL] Emit enqueued block as kernel

In OpenCL the kernel function and non-kernel function has different calling conventions.
For certain targets they have different argument ABIs. Also kernels ha

[OpenCL] Emit enqueued block as kernel

In OpenCL the kernel function and non-kernel function has different calling conventions.
For certain targets they have different argument ABIs. Also kernels have special function
attributes and metadata for runtime to launch them.

The blocks passed to enqueue_kernel is supposed to be executed as kernels. As such,
the block invoke function should be emitted as kernel with proper calling convention and
argument ABI.

This patch emits enqueued block as kernel. If a block is both called directly and passed
to enqueue_kernel, separate functions will be generated.

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

llvm-svn: 315804

show more ...