[HIP][Clang][CodeGen] Add CodeGen support for `hipstdpar`

This patch adds the CodeGen changes needed for enabling HIP parallel algorithm offload on AMDGPU targets. This change relaxes restrictions o

[HIP][Clang][CodeGen] Add CodeGen support for `hipstdpar`

This patch adds the CodeGen changes needed for enabling HIP parallel algorithm offload on AMDGPU targets. This change relaxes restrictions on what gets emitted on the device path, when compiling in `hipstdpar` mode:

1. Unless a function is explicitly marked `__host__`, it will get emitted, whereas before only `__device__` and `__global__` functions would be emitted;
2. Unsupported builtins are ignored as opposed to being marked as an error, as the decision on their validity is deferred to the `hipstdpar` specific code selection pass;
3. We add a `hipstdpar` specific pass to the opt pipeline, independent of optimisation level:
- When compiling for the host, iff the user requested it via the `--hipstdpar-interpose-alloc` flag, we add a pass which replaces canonical allocation / deallocation functions with accelerator aware equivalents.

A test to validate that unannotated functions get correctly emitted is added as well.

Reviewed by: yaxunl, efriedma

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

show more ...

[clang] __is_trivially_equality_comparable for types containing lambdas (#68506)

Lambdas (closure types) are trivially equality-comparable iff they are
non-capturing, because non-capturing lambdas a

[clang] __is_trivially_equality_comparable for types containing lambdas (#68506)

Lambdas (closure types) are trivially equality-comparable iff they are
non-capturing, because non-capturing lambdas are convertible to function
pointers: if (lam1 == lam2) compiles, then lam1 and lam2 must have
the same type, and be always-equal, and be empty.

show more ...

-fsanitize=function: fix MSVC hashing to sugared type (#66816)

Hashing the sugared type instead of the canonical type meant that
a simple example like this would always fail under MSVC:

```
sta

-fsanitize=function: fix MSVC hashing to sugared type (#66816)

Hashing the sugared type instead of the canonical type meant that
a simple example like this would always fail under MSVC:

```
static auto l() {}
int main() {
auto a = l;
a();
}
```
`clang --target=x86_64-pc-windows-msvc -fno-exceptions
-fsanitize=function -g -O0 -fuse-ld=lld -o test.exe test.cc`

produces:
```
test.cc:4:3: runtime error: call to function l through pointer to incorrect function type 'void (*)()'
```

show more ...

[C++] Implement "Deducing this" (P0847R7)

This patch implements P0847R7 (partially),
CWG2561 and CWG2653.

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

Differential Revision: https://reviews.llvm

[C++] Implement "Deducing this" (P0847R7)

This patch implements P0847R7 (partially),
CWG2561 and CWG2653.

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

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

show more ...

[X86] __builtin_cpu_supports: support x86-64{,-v2,-v3,-v4}

GCC 12 (https://gcc.gnu.org/PR101696) allows
__builtin_cpu_supports("x86-64") (and -v2 -v3 -v4).
This patch ports the feature.

* Add `FEAT

[X86] __builtin_cpu_supports: support x86-64{,-v2,-v3,-v4}

GCC 12 (https://gcc.gnu.org/PR101696) allows
__builtin_cpu_supports("x86-64") (and -v2 -v3 -v4).
This patch ports the feature.

* Add `FEATURE_X86_64_{BASELINE,V2,V3,V4}` to enum ProcessorFeatures,
but keep CPU_FEATURE_MAX unchanged to make
FeatureInfos/FeatureInfos_WithPLUS happy.
* Change validateCpuSupports to allow `x86-64{,-v2,-v3,-v4}`
* Change getCpuSupportsMask to return `std::array<uint32_t, 4>` where
`x86-64{,-v2,-v3,-v4}` set bits `FEATURE_X86_64_{BASELINE,V2,V3,V4}`.
* `target("x86-64")` and `cpu_dispatch(x86_64)` are invalid. Tested by commit 9de3b35ac9159d5bae6e6796cb91e4f877a07189

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

Reviewed By: pengfei

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

show more ...

[X86] Support arch=x86-64{,-v2,-v3,-v4} for target_clones attribute

GCC 12 (https://gcc.gnu.org/PR101696) allows `arch=x86-64`
`arch=x86-64-v2` `arch=x86-64-v3` `arch=x86-64-v4` in the
target_clones

[X86] Support arch=x86-64{,-v2,-v3,-v4} for target_clones attribute

GCC 12 (https://gcc.gnu.org/PR101696) allows `arch=x86-64`
`arch=x86-64-v2` `arch=x86-64-v3` `arch=x86-64-v4` in the
target_clones function attribute. This patch ports the feature.

* Set KeyFeature to `x86-64{,-v2,-v3,-v4}` in `Processors[]`, to be used
by X86TargetInfo::multiVersionSortPriority
* builtins: change `__cpu_features2` to an array like libgcc. Define
`FEATURE_X86_64_{BASELINE,V2,V3,V4}` and depended ISA feature bits.
* CGBuiltin.cpp: update EmitX86CpuSupports to handle `arch=x86-64*`.

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

Reviewed By: pengfei

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

show more ...

[CodeGen][UBSan] Handle sugared QualTypes correctly in
getUBSanFunctionTypeHash.

getUBSanFunctionTypeHash checks if a Type is a FunctionNoPrototype
by calling isa<FunctionNoProtoType>(). This does n

[CodeGen][UBSan] Handle sugared QualTypes correctly in
getUBSanFunctionTypeHash.

getUBSanFunctionTypeHash checks if a Type is a FunctionNoPrototype
by calling isa<FunctionNoProtoType>(). This does not work correctly when
the Type is wrapped in a sugar type such as an AttributedType. This
patch fixes this by using isFunctionNoProtoType() function which removes
sugar and returns the expected result.

The added test is a sanity check that the compiler no longer crashes
during compilation. It also compares the hash with and without the
function attribute for both FunctionNoProtoType and FunctionProtoType.
The hash remains the same for FunctionNoProtoType even with the addition
of an attribute.

rdar://113144087

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

show more ...

[clang] Drop some references to typed pointers (getInt8PtrTy). NFC

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

[clang][CodeGen] Drop some typed pointer bitcasts

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

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

-fsanitize=function,MicrosoftMangle: Switch to xxh3_64bits

Following recent changes switching from xxh64 to xxh32 for better
hashing performance (e.g., D154813). These particular instances likely
ha

-fsanitize=function,MicrosoftMangle: Switch to xxh3_64bits

Following recent changes switching from xxh64 to xxh32 for better
hashing performance (e.g., D154813). These particular instances likely
have negligible time, but this change moves us toward removing xxHash64.

The type hash for -fsanitize=function will change, following a recent
change D148785 (not in any release yet) to the type hash scheme, though
sanitizers don't sign up for cross-version compatibility anyway.

The MicrosoftMangle instance is for internal symbols that need no
compatibility guarantee, as emphasized by the comment.

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

[clang] Replace uses of CGBuilderTy::CreateElementBitCast (NFC)

* Add `Address::withElementType()` as a replacement for
`CGBuilderTy::CreateElementBitCast`.

* Partial progress towards replacing `

[clang] Replace uses of CGBuilderTy::CreateElementBitCast (NFC)

* Add `Address::withElementType()` as a replacement for
`CGBuilderTy::CreateElementBitCast`.

* Partial progress towards replacing `CreateElementBitCast`, as it no
longer does what its name suggests. Either replace its uses with
`Address::withElementType()`, or remove them if no longer needed.

* Remove unused parameter 'Name' of `CreateElementBitCast`

Reviewed By: barannikov88, nikic

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

show more ...

[Clang] Remove uses of PointerType::getWithSamePointeeType (NFC)

No longer relevant with opaque pointers.

-fsanitize=function: support C

With D148785, -fsanitize=function no longer uses C++ RTTI objects and therefore
can support C. The rationale for reporting errors is C11 6.5.2.2p9:

> If the function

-fsanitize=function: support C

With D148785, -fsanitize=function no longer uses C++ RTTI objects and therefore
can support C. The rationale for reporting errors is C11 6.5.2.2p9:

> If the function is defined with a type that is not compatible with the type (of the expression) pointed to by the expression that denotes the called function, the behavior is undefined.

The mangled types approach we use does not exactly match the C type
compatibility (see `f(callee1)` below).
This is probably fine as the rules are unlikely leveraged in practice. In
addition, the call is warned by -Wincompatible-function-pointer-types-strict.

```
void callee0(int (*a)[]) {}
void callee1(int (*a)[1]) {}
void f(void (*fp)(int (*)[])) { fp(0); }
int main() {
int a[1];
f(callee0);
f(callee1); // compatible but flagged by -fsanitize=function, -fsanitize=kcfi, and -Wincompatible-function-pointer-types-strict
}
```

Skip indirect call sites of a function type without a prototype to avoid deal
with C11 6.5.2.2p6. -fsanitize=kcfi skips such calls as well.

Reviewed By: #sanitizers, vitalybuka

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

show more ...

-fsanitize=function: use type hashes instead of RTTI objects

Currently we use RTTI objects to check type compatibility. To support non-unique
RTTI objects, commit 5745eccef54ddd3caca278d1d292a88b228

-fsanitize=function: use type hashes instead of RTTI objects

Currently we use RTTI objects to check type compatibility. To support non-unique
RTTI objects, commit 5745eccef54ddd3caca278d1d292a88b2281528b added a
`checkTypeInfoEquality` string matching to the runtime.
The scheme is inefficient.

```
_Z1fv:
.long 846595819 # jmp
.long .L__llvm_rtti_proxy-_Z3funv
...

main:
...
# Load the second word (pointer to the RTTI object) and dereference it.
movslq 4(%rsi), %rax
movq (%rax,%rsi), %rdx
# Is it the desired typeinfo object?
leaq _ZTIFvvE(%rip), %rax
# If not, call __ubsan_handle_function_type_mismatch_v1, which may recover if checkTypeInfoEquality allows
cmpq %rax, %rdx
jne .LBB1_2
...

.section .data.rel.ro,"aw",@progbits
.p2align 3, 0x0
.L__llvm_rtti_proxy:
.quad _ZTIFvvE
```

Let's replace the indirect `_ZTI` pointer with a type hash similar to
`-fsanitize=kcfi`.

```
_Z1fv:
.long 3238382334
.long 2772461324 # type hash

main:
...
# Load the second word (callee type hash) and check whether it is expected
cmpl $-1522505972, -4(%rax)
# If not, fail: call __ubsan_handle_function_type_mismatch
jne .LBB2_2
```

The RTTI object derives its name from `clang::MangleContext::mangleCXXRTTI`,
which uses `mangleType`. `mangleTypeName` uses `mangleType` as well. So the
type compatibility change is high-fidelity.

Since we no longer need RTTI pointers in
`__ubsan::__ubsan_handle_function_type_mismatch_v1`, let's switch it back to
version 0, the original signature before
e215996a2932ed7c472f4e94dc4345b30fd0c373 (2019).
`__ubsan::__ubsan_handle_function_type_mismatch_abort` is not
recoverable, so we can revert some changes from
e215996a2932ed7c472f4e94dc4345b30fd0c373.

Reviewed By: samitolvanen

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

show more ...

[IR] Adds Instruction::setNoSanitizeMetadata()

This patch adds a new method setNoSanitizeMetadata() for Instruction, and use it in SanitizerMetadata and SanitizerCoverage.

Reviewed By: nickdesaulni

[IR] Adds Instruction::setNoSanitizeMetadata()

This patch adds a new method setNoSanitizeMetadata() for Instruction, and use it in SanitizerMetadata and SanitizerCoverage.

Reviewed By: nickdesaulniers, MaskRay

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

show more ...

[SanitizerBinaryMetadata] Respect no_sanitize("thread") function attribute

To avoid false positives, respect no_sanitize("thread") when atomics
metadata is enabled.

Reviewed By: dvyukov

Differenti

[SanitizerBinaryMetadata] Respect no_sanitize("thread") function attribute

To avoid false positives, respect no_sanitize("thread") when atomics
metadata is enabled.

Reviewed By: dvyukov

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

show more ...

[Clang] Check feature requirement from inlined callee

Currently clang emits error when both always_inline and target
attributes are on callee, but caller doesn't have some feature.

This patch makes

[Clang] Check feature requirement from inlined callee

Currently clang emits error when both always_inline and target
attributes are on callee, but caller doesn't have some feature.

This patch makes clang emit error when caller cannot meet target feature
requirements from an always-inlined callee.

Reviewed By: erichkeane

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

show more ...

[CodeGen] Add a flag to `Address` and `Lvalue` that is used to keep
track of whether the pointer is known not to be null

The flag will be used for the arm64e work we plan to upstream in the
future (

[CodeGen] Add a flag to `Address` and `Lvalue` that is used to keep
track of whether the pointer is known not to be null

The flag will be used for the arm64e work we plan to upstream in the
future (see https://lists.llvm.org/pipermail/llvm-dev/2019-October/136091.html).
Currently the flag has no effect on code generation.

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

show more ...

[CodeGen] bugfix: ApplyDebugLocation goes out of scope before intended

rdar://103570533

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

[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] Use the TypeSize::getXXXValue() instead of TypeSize::getXXXSize)

This change is one of a series to implement the discussion from
https://reviews.llvm.org/D141134.