Revert "[C++20] [Modules] Don't import non-inline function bodies even if it is marked as always_inline"

This reverts commit 1ecbab56dcbb78268c8d19af34a50591f90b12a0.

See the discussion in https://

Revert "[C++20] [Modules] Don't import non-inline function bodies even if it is marked as always_inline"

This reverts commit 1ecbab56dcbb78268c8d19af34a50591f90b12a0.

See the discussion in https://github.com/llvm/llvm-project/issues/86893.

The original commit receives too many complaints. Let's try to
workaround the issue to give better user experiences.

show more ...

[clang][llvm] Remove "implicit-section-name" attribute (#87906)

D33412/D33413 introduced this to support a clang pragma to set section
names for a symbol depending on if it would be placed in
bss/

[clang][llvm] Remove "implicit-section-name" attribute (#87906)

D33412/D33413 introduced this to support a clang pragma to set section
names for a symbol depending on if it would be placed in
bss/data/rodata/text, which may not be known until the backend. However,
for text we know that only functions will go there, so just directly set
the section in clang instead of going through a completely separate
attribute.

Autoupgrade the "implicit-section-name" attribute to directly setting
the section on a Fuction.

show more ...

[NFC][Clang] Improve const correctness for IdentifierInfo (#79365)

The IdentifierInfo isn't typically modified. Use 'const' wherever
possible.

[ARM64EC] Add support for parsing __vectorcall (#87725)

MSVC doesn't support generating __vectorcall calls in Arm64EC mode, but
it does treat it as a distinct type. The Microsoft STL depends on thi

[ARM64EC] Add support for parsing __vectorcall (#87725)

MSVC doesn't support generating __vectorcall calls in Arm64EC mode, but
it does treat it as a distinct type. The Microsoft STL depends on this
functionality. (Not sure if this is intentional.) Add support for
parsing the same way as MSVC, and add some checks to ensure we don't try
to actually generate code.

The error handling in CodeGen is ugly, but I can't think of a better way
to do it.

show more ...

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

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

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

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

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

[FMV] Allow mixing target_version with target_clones. (#86493)

The latest ACLE allows it and further clarifies the following
in regards to the combination of the two attributes:

"If the `default

[FMV] Allow mixing target_version with target_clones. (#86493)

The latest ACLE allows it and further clarifies the following
in regards to the combination of the two attributes:

"If the `default` matches with another explicitly provided
version in the same translation unit, then the compiler can
emit only one function instead of the two. The explicitly
provided version shall be preferred."

("default" refers to the default clone here)

https://github.com/ARM-software/acle/pull/310

show more ...

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

[FMV] Allow multi versioning without default declaration. (#85454)

This was a limitation which has now been lifted. Please read the
thread below for more details:

https://github.com/llvm/llvm-pr

[FMV] Allow multi versioning without default declaration. (#85454)

This was a limitation which has now been lifted. Please read the
thread below for more details:

https://github.com/llvm/llvm-project/pull/84405#discussion_r1525583647

Basically it allows to separate versioned implementations across
different TUs without having to share private header files which
contain the default declaration.

The ACLE spec has been updated accordingly to make this explicit:
"Each version declaration should be visible at the translation
unit in which the corresponding function version resides."

https://github.com/ARM-software/acle/pull/310

If a resolver is required (because there is a caller in the TU),
then a default declaration is implicitly generated.

show more ...

Reland [FMV] Emit the resolver along with the default version definit… (#85923)

…ion.

This was reverted because the resolver didn't look as expected in one of
the tests. I believe it had some in

Reland [FMV] Emit the resolver along with the default version definit… (#85923)

…ion.

This was reverted because the resolver didn't look as expected in one of
the tests. I believe it had some interaction with #84146. I have now
regenerated it using -target-feature -fp-armv8.

show more ...

Revert "[FMV] Emit the resolver along with the default version definition." (#85914)

Reverts llvm/llvm-project#84405

In between of passing the precommit tests on github and being merged
some cha

Revert "[FMV] Emit the resolver along with the default version definition." (#85914)

Reverts llvm/llvm-project#84405

In between of passing the precommit tests on github and being merged
some change (perhaps in the AArch64 backend?) landed which resulted
in altering the generated resolver. I will regenerate the tests
perhaps using a less sensitive runline to such changes.

show more ...

[FMV] Emit the resolver along with the default version definition. (#84405)

We would like the resolver to be generated eagerly, even if the
versioned function is not called from the current transla

[FMV] Emit the resolver along with the default version definition. (#84405)

We would like the resolver to be generated eagerly, even if the
versioned function is not called from the current translation
unit. Fixes #81494. It further allows Multi Versioning to work
even if the default target version attribute is omitted from
function declarations.

show more ...

[AArch64] Add soft-float ABI (#84146)

This is re-working of #74460, which adds a soft-float ABI for AArch64.
That was reverted because it causes errors when building the linux and
fuchsia kernels.

[AArch64] Add soft-float ABI (#84146)

This is re-working of #74460, which adds a soft-float ABI for AArch64.
That was reverted because it causes errors when building the linux and
fuchsia kernels.

The problem is that GCC's implementation of the ABI compatibility checks
when using the hard-float ABI on a target without FP registers does it's
checks after optimisation. The previous version of this patch reported
errors for all uses of floating-point types, which is stricter than what
GCC does in practice.

This changes two things compared to the first version:
* Only check the types of function arguments and returns, not the types
of other values. This is more relaxed than GCC, while still guaranteeing
ABI compatibility.
* Move the check from Sema to CodeGen, so that inline functions are only
checked if they are actually used. There are some cases in the linux
kernel which depend on this behaviour of GCC.

show more ...

[AIX][TOC] Add -mtocdata/-mno-tocdata options on AIX (#67999)

This patch enables support that the XL compiler had for AIX under
-qdatalocal/-qdataimported.

[HIP] Do not include the CUID module hash with the new driver (#84332)

Summary:
The new driver does not need this hash and it can lead to redefined
symbol errors when the CUID hash isn't set.

[AMDGPU] Rename COV module flag to amdhsa_code_object_version (#79905)

The previous name 'amdgpu_code_object_version', was misleading since
this is really a property of the HSA OS. The new spelling

[AMDGPU] Rename COV module flag to amdhsa_code_object_version (#79905)

The previous name 'amdgpu_code_object_version', was misleading since
this is really a property of the HSA OS. The new spelling also matches
the asm directive I added in bc82cfb.

show more ...

[clang] Refactor target attribute mangling. (#81893)

Before this patch all of the 'target', 'target_version' and
'target_clones' attributes were sharing a common mangling logic across
different ta

[clang] Refactor target attribute mangling. (#81893)

Before this patch all of the 'target', 'target_version' and
'target_clones' attributes were sharing a common mangling logic across
different targets. However we would like to differenciate this logic,
therefore I have moved the default path to ABIInfo and provided
overrides for AArch64. This way we can resolve feature aliases without
affecting the name mangling. The PR #80540 demonstrates a motivating
case.

show more ...

[TBAA] Handle bitfields when generating !tbaa.struct metadata. (#82922)

At the moment, clang generates what I believe are incorrect !tbaa.struct
fields for named bitfields. At the moment, the base

[TBAA] Handle bitfields when generating !tbaa.struct metadata. (#82922)

At the moment, clang generates what I believe are incorrect !tbaa.struct
fields for named bitfields. At the moment, the base type size is used
for named bifields (e.g. sizeof(int)) instead of the bifield width per
field. This results in overalpping fields in !tbaa.struct metadata.

This causes incorrect results when extracting individual copied fields
from !tbaa.struct as in added in dc85719d5.

This patch fixes that by skipping by combining adjacent bitfields
in fields with correct sizes.

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

show more ...

[InstrProf] Single byte counters in coverage (#75425)

This patch inserts 1-byte counters instead of an 8-byte counters into
llvm profiles for source-based code coverage. The origial idea was
propo

[InstrProf] Single byte counters in coverage (#75425)

This patch inserts 1-byte counters instead of an 8-byte counters into
llvm profiles for source-based code coverage. The origial idea was
proposed as block-cov for PGO, and this patch repurposes that idea for
coverage: https://groups.google.com/g/llvm-dev/c/r03Z6JoN7d4

The current 8-byte counters mechanism add counters to minimal regions,
and infer the counters in the remaining regions via adding or
subtracting counters. For example, it infers the counter in the if.else
region by subtracting the counters between if.entry and if.then regions
in an if statement. Whenever there is a control-flow merge, it adds the
counters from all the incoming regions. However, we are not going to be
able to infer counters by subtracting two execution counts when using
single-byte counters. Therefore, this patch conservatively inserts
additional counters for the cases where we need to add or subtract
counters.

RFC:
https://discourse.llvm.org/t/rfc-single-byte-counters-for-source-based-code-coverage/75685

show more ...

[HIP] Allow partial linking for `-fgpu-rdc` (#81700)

`-fgpu-rdc` mode allows device functions call device functions in
different TU. However, currently all device objects have to be linked
togethe

[HIP] Allow partial linking for `-fgpu-rdc` (#81700)

`-fgpu-rdc` mode allows device functions call device functions in
different TU. However, currently all device objects have to be linked
together since only one fat binary is supported. This is time consuming
for AMDGPU backend since it only supports LTO.

There are use cases that objects can be divided into groups in which
device functions are self-contained but host functions are not. It is
desirable to link/optimize/codegen the device code and generate a fatbin
for each group, whereas partially link the host code with `ld -r` or
generate a static library by using the `--emit-static-lib` option of
clang. This avoids linking all device code together, therefore decreases
the linking time for `-fgpu-rdc`.

Previously, clang emits an external symbol `__hip_fatbin` for all
objects for `-fgpu-rdc`. With this patch, clang emits an unique external
symbol `__hip_fatbin_{cuid}` for the fat binary for each object. When a
group of objects are linked together to generate a fatbin, the symbols
are merged by alias and point to the same fat binary. Each group has its
own fat binary. One executable or shared library can have multiple fat
binaries. Device linking is done for undefined fab binary symbols only
to avoid repeated linking. `__hip_gpubin_handle` is also uniquefied and
merged to avoid repeated registering. Symbol `__hip_cuid_{cuid}` is
introduced to facilitate debugging and tooling.

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

show more ...

[OpenMP] Remove `register_requires` global constructor (#80460)

Summary:
Currently, OpenMP handles the `omp requires` clause by emitting a global
constructor into the runtime for every translation u

[OpenMP] Remove `register_requires` global constructor (#80460)

Summary:
Currently, OpenMP handles the `omp requires` clause by emitting a global
constructor into the runtime for every translation unit that requires
it. However, this is not a great solution because it prevents us from
having a defined order in which the runtime is accessed and used.

This patch changes the approach to no longer use global constructors,
but to instead group the flag with the other offloading entires that we
already handle. This has the effect of still registering each flag per
requires TU, but now we have a single constructor that handles
everything.

This function removes support for the old `__tgt_register_requires` and
replaces it with a warning message. We just had a recent release, and
the OpenMP policy for the past four releases since we switched to LLVM
is that we do not provide strict backwards compatibility between major
LLVM releases now that the library is versioned. This means that a user
will need to recompile if they have an old binary that relied on
`register_requires` having the old behavior. It is important that we
actively deprecate this, as otherwise it would not solve the problem of
having no defined init and shutdown order for `libomptarget`. The
problem of `libomptarget` not having a define init and shutdown order
cascades into a lot of other issues so I have a strong incentive to be
rid of it.

It is worth noting that the current `__tgt_offload_entry` only has space
for a 32-bit integer here. I am planning to overhaul these at some point
as well.

show more ...

[C++20] [Modules] Don't import non-inline function bodies even if it is marked as always_inline

Close https://github.com/llvm/llvm-project/issues/80949

Previously, I thought the always-inline funct

[C++20] [Modules] Don't import non-inline function bodies even if it is marked as always_inline

Close https://github.com/llvm/llvm-project/issues/80949

Previously, I thought the always-inline function can be an exception to
enable optimizations as much as possible. However, it looks like it
breaks the ABI requirement we discussed later. So it looks better to not
import non-inline function bodies at all even if the function bodies are
marked as always_inline.

It doesn't produce regressions in some degree since the always_inline
still works in the same TU.

show more ...