[Clang][AArch64] Add/implement ACLE keywords for SME.

This patch adds all the language-level function keywords defined in:

https://github.com/ARM-software/acle/pull/188 (merged)
https://github.

[Clang][AArch64] Add/implement ACLE keywords for SME.

This patch adds all the language-level function keywords defined in:

https://github.com/ARM-software/acle/pull/188 (merged)
https://github.com/ARM-software/acle/pull/261 (update after D148700 landed)

The keywords are used to control PSTATE.ZA and PSTATE.SM, which are
respectively used for enabling the use of the ZA matrix array and Streaming
mode. This information needs to be available on call sites, since the use
of ZA or streaming mode may have to be enabled or disabled around the
call-site (depending on the IR attributes set on the caller and the
callee). For calls to functions from a function pointer, there is no IR
declaration available, so the IR attributes must be added explicitly to the
call-site.

With the exception of '__arm_locally_streaming' and '__arm_new_za' the
information is part of the function's interface, not just the function
definition, and thus needs to be propagated through the
FunctionProtoType::ExtProtoInfo.

This patch adds the defintions of these keywords, as well as codegen and
semantic analysis to ensure conversions between function pointers are valid
and that no conflicting keywords are set. For example, '__arm_streaming'
and '__arm_streaming_compatible' are mutually exclusive.

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

show more ...

[X86][Regcall] Add an option to respect regcall ABI v.4 in win64&win32

Reviewed By: pengfei

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

[CodeGen] Assert that EmittedDeferredDecls is empty

Its contents are transferred into DeferredDecls in Release(), so it
should be empty in moveLazyEmissionStates(). This matches the code
downstream

[CodeGen] Assert that EmittedDeferredDecls is empty

Its contents are transferred into DeferredDecls in Release(), so it
should be empty in moveLazyEmissionStates(). This matches the code
downstream in Cling.

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

show more ...

Remove private rdar links. NFC

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

[OpenMP] Do not always emit unused extern variables

Currently, the precense of the OpenMP target declare metadata requires
that we always codegen a global declaration. This is undesirable in the
cas

[OpenMP] Do not always emit unused extern variables

Currently, the precense of the OpenMP target declare metadata requires
that we always codegen a global declaration. This is undesirable in the
case that we could defer or omit this declaration as is common with
unused extern variables. This is important as it allows us, in the
runtime, to rely on static linking semantics to omit unused symbols so
they are not included when the user links it in.

This patch changes the check for always emitting these variables.
Because of this we also need to extend this logic to the generation of
the offloading entries. This has the result of derring the offload entry
generation to the canonical definitoin. So we are effectively assuming
whoever owns the storage for this variable will perform that operation.
This makes an exception for `link` attributes as those require their own
special handling.

Let me know if this is sound in the implementation, I do not have the
largest view of the standards here.

Fixes: https://github.com/llvm/llvm-project/issues/64133

Reviewed By: tianshilei1992

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

show more ...

[Support] Change SetVector's default template parameter to SmallVector<*, 0>

Similar to D156016 for MapVector.

This brings back commit fae7b98c221b5b28797f7b56b656b6b819d99f27 with a
fix to llvm/un

[Support] Change SetVector's default template parameter to SmallVector<*, 0>

Similar to D156016 for MapVector.

This brings back commit fae7b98c221b5b28797f7b56b656b6b819d99f27 with a
fix to llvm/unittests/Support/ThreadPool.cpp's `_WIN32` code path.

show more ...

Revert rGfae7b98c221b5b28797f7b56b656b6b819d99f27 "[Support] Change SetVector's default template parameter to SmallVector<*, 0>"

This is failing on Windows MSVC builds:
llvm\unittests\Support\Thread

Revert rGfae7b98c221b5b28797f7b56b656b6b819d99f27 "[Support] Change SetVector's default template parameter to SmallVector<*, 0>"

This is failing on Windows MSVC builds:
llvm\unittests\Support\ThreadPool.cpp(380): error C2440: 'return': cannot convert from 'Vector' to 'std::vector<llvm::BitVector,std::allocator<llvm::BitVector>>'
with
[
Vector=llvm::SmallVector<llvm::BitVector,0>
]

show more ...

[Support] Change SetVector's default template parameter to SmallVector<*, 0>

Similar to D156016 for MapVector.

[Clang] Fix consteval propagation for aggregates and defaulted constructors

This patch does a few things:

* Fix aggregate initialization.
When an aggregate has an initializer that is immediate-es

[Clang] Fix consteval propagation for aggregates and defaulted constructors

This patch does a few things:

* Fix aggregate initialization.
When an aggregate has an initializer that is immediate-escalating,
the context in which it is used automatically becomes an immediate function.
The wording does that by rpretending an aggregate initialization is itself
an invocation which is not really how clang works, so my previous attempt
was... wrong.

* Fix initialization of defaulted constructors with immediate escalating
default member initializers.
The wording was silent about that case and I did not handled it fully
https://cplusplus.github.io/CWG/issues/2760.html

* Fix diagnostics
In some cases clang would produce additional and unhelpful
diagnostics by listing the invalid references to consteval
function that appear in immediate escalating functions

Fixes https://github.com/llvm/llvm-project/issues/63742

Reviewed By: aaron.ballman, #clang-language-wg, Fznamznon

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

show more ...

[CodeGen] Stabilize C2/D2 to C1/D1 replacement order

The conversion iterates over CodeGenModule::Replacements (a StringMap)
and replaces C2/D2 and moves C1/D1 (
commit 0196a1d98f8a206259a4b5ce93c218

[CodeGen] Stabilize C2/D2 to C1/D1 replacement order

The conversion iterates over CodeGenModule::Replacements (a StringMap)
and replaces C2/D2 and moves C1/D1 (
commit 0196a1d98f8a206259a4b5ce93c21807243af92f in 2013, to make the
output look nicer). The iteration order is not guaranteed to be
deterministic, and may cause destructors.cpp to exhibit different
function orders. Use a MapVector instead.

While here, fix an IWYU issue by adding an explicit include, though
MapVector is already used in CodeGenModule.h.

show more ...

Optimize emission of `dynamic_cast` to final classes.

- When the destination is a final class type that does not derive from
the source type, the cast always fails and is now emitted as a null
p

Optimize emission of `dynamic_cast` to final classes.

- When the destination is a final class type that does not derive from
the source type, the cast always fails and is now emitted as a null
pointer or call to __cxa_bad_cast.

- When the destination is a final class type that does derive from the
source type, emit a direct comparison against the corresponding base
class vptr value(s). There may be more than one such value in the case
of multiple inheritance; check them all.

For now, this is supported only for the Itanium ABI. I expect the same thing is
possible for the MS ABI too, but I don't know what guarantees are made about
vfptr uniqueness.

Reviewed By: rjmccall

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

show more ...

[NFC] Remove needless nullchecks.

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

[Clang][CodeGen]`vtable`, `typeinfo` et al. are globals

All data structures and values associated with handling virtual functions / inheritance, as well as RTTI, are globals and thus can only reside

[Clang][CodeGen]`vtable`, `typeinfo` et al. are globals

All data structures and values associated with handling virtual functions / inheritance, as well as RTTI, are globals and thus can only reside in the global address space. This was not taken fully taken into account because for most targets, global & generic appear to coincide. However, on targets where global & generic ASes differ (e.g. AMDGPU), this was problematic, since it led to the generation of invalid bitcasts (which would trigger asserts in Debug) and less than optimal code. This patch does two things:

ensures that vtables, vptrs, vtts, typeinfo are generated in the right AS, and populated accordingly;
removes a bunch of bitcasts which look like left-overs from the typed ptr era.

Reviewed By: yxsamliu

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

show more ...

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it land

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it landed. According to our developer policy
this warrants immediate revert of the commit.

https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy

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

show more ...

Add option -fkeep-persistent-storage-variables to emit all variables that have a persistent storage duration

This patch adds a new option -fkeep-persistent-storage-variables to emit
all variables th

Add option -fkeep-persistent-storage-variables to emit all variables that have a persistent storage duration

This patch adds a new option -fkeep-persistent-storage-variables to emit
all variables that have a persistent storage duration, including global,
static and thread-local variables. This could be useful in cases where
the presence of all these variables as symbols in the object file are
required, so that they can be directly addressed.

Reviewed By: hubert.reinterpretcast

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

show more ...

[CodeGen][NFCI] Avoid calls to setTargetAttributes on definitions

Avoid duplicate calls to setTargetAttributes on global variable definitions.

Differential: https://reviews.llvm.org/D153903

[OpenMP][OMPIRBuilder] Rename IsEmbedded and IsTargetCodegen flags

This patch renames the `OpenMPIRBuilderConfig` flags to reduce confusion over
their meaning. `IsTargetCodegen` becomes `IsGPU`, whe

[OpenMP][OMPIRBuilder] Rename IsEmbedded and IsTargetCodegen flags

This patch renames the `OpenMPIRBuilderConfig` flags to reduce confusion over
their meaning. `IsTargetCodegen` becomes `IsGPU`, whereas `IsEmbedded` becomes
`IsTargetDevice`. The `-fopenmp-is-device` compiler option is also renamed to
`-fopenmp-is-target-device` and the `omp.is_device` MLIR attribute is renamed
to `omp.is_target_device`. Getters and setters of all these renamed properties
are also updated accordingly. Many unit tests have been updated to use the new
names, but an alias for the `-fopenmp-is-device` option is created so that
external programs do not stop working after the name change.

`IsGPU` is set when the target triple is AMDGCN or NVIDIA PTX, and it is only
valid if `IsTargetDevice` is specified as well. `IsTargetDevice` is set by the
`-fopenmp-is-target-device` compiler frontend option, which is only added to
the OpenMP device invocation for offloading-enabled programs.

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

show more ...

clang: Stop emitting "strictfp"

The attribute is a proper enum attribute, strictfp. We were getting
strictfp and "strictfp" set on every function with
-fexperimental-strict-floating-point.

https://

clang: Stop emitting "strictfp"

The attribute is a proper enum attribute, strictfp. We were getting
strictfp and "strictfp" set on every function with
-fexperimental-strict-floating-point.

https://reviews.llvm.org/D139629

show more ...

[Clang] Emit KCFI type hashes for member functions

With `-fsanitize=kcfi`, Clang currently won't emit type hashes for
C++ member functions, which leads to check failures if they are
indirectly calle

[Clang] Emit KCFI type hashes for member functions

With `-fsanitize=kcfi`, Clang currently won't emit type hashes for
C++ member functions, which leads to check failures if they are
indirectly called. As there's no reason to exclude member functions
in CodeGenModule::setKCFIType, emit type hashes also for them to fix
member function pointer calls with KCFI, and add a test to confirm
that types are emitted correctly.

show more ...

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-rev

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-review-reminder-about-links-in-code-commit-messages/71847

show more ...

[clang][CodeGenCXX] Improve handling of itanium ABI member function alignment requirements

The itanium ABI for certain platforms requires a minimum alignments for
member function pointers to reserve

[clang][CodeGenCXX] Improve handling of itanium ABI member function alignment requirements

The itanium ABI for certain platforms requires a minimum alignments for
member function pointers to reserve certain bits for distinguishing
virtual and non-virtual functions.

Our implementation of this however depends on the alignment of the
function involved, which may however not reflect the true alignment of
function pointers on certain targets for which the alignment is
independent of the function (e.g. AIX). Worse, the 2-byte alignment
we use may be less than the ABI minimum for the target, and in the case
we are using explicit sections will result in invalid codegen.

This patch attempts to correct this situation by considering the target
alignment of function pointers as part of making the decision about
whether we need to adjust the function alignment to conform to the ABI.
Targets which do not provide the function ptr alignment information
will return a value of 1 when queried and will conservatively retain
the old alignment.

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

show more ...

[X86] Remove CPU_SPECIFIC* MACROs and add getCPUDispatchMangling

This refactor patch means to remove CPU_SPECIFIC* MACROs in X86TargetParser.def
and move those information into ProcInfo of X86Target

[X86] Remove CPU_SPECIFIC* MACROs and add getCPUDispatchMangling

This refactor patch means to remove CPU_SPECIFIC* MACROs in X86TargetParser.def
and move those information into ProcInfo of X86TargetParser.cpp. Since these
two files both maintain a table with redundant info such as cpuname and its
features supported. CPU_SPECIFIC* MACROs define some different information. This
patch dealt with them in these ways when moving:
1.mangling
This is now moved to Mangling in ProcInfo and directly initialized at array of
Processors. CPUs don't support cpu_dispatch/specific are assigned '\0' as
mangling.
2.CPU alias
The alias cpu will also be initialized in array of Processors, its attributes
will be same as its alias target cpu. Same feature list, same mangling.
3.TUNE_NAME
Before my change, some cpu names support cpu_dispatch/specific are not
supported in X86.td, which means optimizer/backend doesn't recognize them. So
they use a different TUNE_NAME to generate in IR. In this patch, I added these
missing cpu support at X86.td by utilizing existing Features and XXXTunings, so
that each cpu name can directly use its own name as TUNE_NAME to be supported
by optimizer/backend.
4.Feature list
The feature list of one CPU maintained in X86TargetParser.def is not same as
the one in X86TargetParser.cpp. It only maintains part of features of one CPU
(features defined by X86_FEATURE_COMPAT). While X86TargetParser.cpp maintains
a complete one. This patch abandons the feature list maintained by CPU_SPECIFIC*
MACROs because assigning a CPU with a complete one doesn't affect the
functionality of cpu_dispatch/specific.
Except these four info, since some of CPUs supported by cpu_dispatch/specific
doesn's support clang options like -march, -mtune before, this patch also kept
this behavior still by adding another member OnlyForCPUDispatchSpecific in
ProcInfo.

Reviewed By: pengfei, RKSimon

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

show more ...

[llvm] Move AttributeMask to a separate header

Move `AttributeMask` out of `llvm/IR/Attributes.h` to a new file
`llvm/IR/AttributeMask.h`. After doing this we can remove the
`#include <bitset>` and

[llvm] Move AttributeMask to a separate header

Move `AttributeMask` out of `llvm/IR/Attributes.h` to a new file
`llvm/IR/AttributeMask.h`. After doing this we can remove the
`#include <bitset>` and `#include <set>` directives from `Attributes.h`.
Since there are many headers including `Attributes.h`, but not needing
the definition of `AttributeMask`, this causes unnecessary bloating of
the translation units and slows down compilation.

This commit adds in the include directive for `llvm/IR/AttributeMask.h`
to the handful of source files that need to see the definition.

This reduces the total number of preprocessing tokens across the LLVM
source files in lib from (roughly) 1,917,509,187 to 1,902,982,273 - a
reduction of ~0.76%. This should result in a small improvement in
compilation time.

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

show more ...

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

[CodeGen] Remove unused function GetOrCreateRTTIProxyGlobalVariable

The last use was removed by:

commit 46f366494f3ca8cc98daa6fb4f29c7c446c176b6
Author: Fangrui Song <i@maskray.me>
Date: Sa

[CodeGen] Remove unused function GetOrCreateRTTIProxyGlobalVariable

The last use was removed by:

commit 46f366494f3ca8cc98daa6fb4f29c7c446c176b6
Author: Fangrui Song <i@maskray.me>
Date: Sat May 20 08:24:20 2023 -0700

This patch also removes RTTIProxyMap, which becomes unused once I
remove GetOrCreateRTTIProxyGlobalVariable.

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

show more ...