[PAC][Driver] Support `pauthtest` ABI for AArch64 Linux triples (#97237)

When `pauthtest` is either passed as environment part of AArch64 Linux
triple
or passed via `-mabi=`, enable the following

[PAC][Driver] Support `pauthtest` ABI for AArch64 Linux triples (#97237)

When `pauthtest` is either passed as environment part of AArch64 Linux
triple
or passed via `-mabi=`, enable the following ptrauth flags:

- `intrinsics`;
- `calls`;
- `returns`;
- `auth-traps`;
- `vtable-pointer-address-discrimination`;
- `vtable-pointer-type-discrimination`;
- `init-fini`.

Some related stuff is still subject to change, and the ABI itself might
be changed, so end users are not expected to use this and the ABI name
has 'test' suffix.

If `-mabi=pauthtest` option is used, it's normalized to effective
triple.

When the environment part of the effective triple is `pauthtest`, try
to use `aarch64-linux-pauthtest` as multilib directory.

The following is not supported:
- combination of `pauthtest` ABI with any branch protection scheme
except BTI;
- explicit set of environment part of the triple to a value different
from `pauthtest` in combination with `-mabi=pauthtest`;
- usage on non-Linux OS.

---------

Co-authored-by: Anatoly Trosinenko <atrosinenko@accesssoftek.com>

show more ...

[FMV][AArch64] Do not emit ifunc resolver on use. (#97761)

It was raised in https://github.com/llvm/llvm-project/issues/81494 that
we are not generating correct code when there is no TU-local calle

[FMV][AArch64] Do not emit ifunc resolver on use. (#97761)

It was raised in https://github.com/llvm/llvm-project/issues/81494 that
we are not generating correct code when there is no TU-local caller.

The suggestion was to emit a resolver:
* Whenever there is a use in the TU.
* When the TU has a definition of the default version.

See the comment for more details:

https://github.com/llvm/llvm-project/issues/81494#issuecomment-1985963497

This got addressed with https://github.com/llvm/llvm-project/pull/84405.

Generating a resolver on use means that we may end up with multiple
resolvers across different translation units. Those resolvers may not be
the same because each translation unit may contain different version
declarations (user's fault). Therefore the order of linking the final
image determines which of these weak symbols gets selected, resulting in
non consisted behavior. I am proposing to stop emitting a resolver on
use and only do so in the translation unit which contains the default
definition. This way we guarantee the existence of a single resolver.
Now, when a versioned function is used we want to emit a declaration of
the function symbol omitting the multiversion mangling.

I have added a requirement to ACLE mandating that all the function
versions are declared in the translation unit which contains the default
definition: https://github.com/ARM-software/acle/pull/328

show more ...

Revert "Finish deleting the le32/le64 targets" (#99079)

Reverts llvm/llvm-project#98497

We're reverting this for approx 30 days so that the Halide project has
time to transition off the target.

[CodeGen] Set attributes on resolvers emitted after ifuncs

Visiting the ifunc calls `GetOrCreateLLVMFunction` with
`NotForDefinition` while visiting the resolver calls
`GetOrCreateLLVMFunction` with

[CodeGen] Set attributes on resolvers emitted after ifuncs

Visiting the ifunc calls `GetOrCreateLLVMFunction` with
`NotForDefinition` while visiting the resolver calls
`GetOrCreateLLVMFunction` with `ForDefinition`.

When an ifunc is emitted before its resolver, the `ForDefinition` call
does not call `SetFunctionAttributes`, because the function prematurely
returns due to `(Entry->getValueType() == Ty)` and
`llvm::GlobalIFunc::getResolverFunctionType(DeclTy)`.

This leads to missing `!kcfi_type` with -fsanitize=kcfi.

```
extern void ifunc0(void) __attribute__ ((ifunc("resolver0")));
void *resolver0(void) { return 0; } // SetFunctionAttributes not called

extern void ifunc1(void) __attribute__ ((ifunc("resolver1")));
static void *resolver1(void) { return 0; } // SetFunctionAttributes not called

extern void ifunc2(void) __attribute__ ((ifunc("resolver2")));
static void *resolver2(void*) { return 0; }
```

Ensure `SetFunctionAttributes` is called by calling
`GetOrCreateLLVMFunction` with a dummy non-function type. Now that the
`F->takeName(Entry)` code path may be taken, the
`DisableSanitizerInstrumentation` code
(https://reviews.llvm.org/D150262) should be moved to `checkAliases`,
when the resolver function is finalized.

Pull Request: https://github.com/llvm/llvm-project/pull/98832

show more ...

[CUDA][HIP] Fix template static member (#98580)

Should check host/device attributes before emitting static member of
template instantiation.

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

[CUDA][HIP] Fix template static member (#98580)

Should check host/device attributes before emitting static member of
template instantiation.

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

show more ...

Finish deleting the le32/le64 targets (#98497)

This is a revert of ef5e7f90ea4d5063ce68b952c5de473e610afc02 which was a
temporary partial revert of 77ac823fd285973cfb3517932c09d82e6a32f46d.
The le

Finish deleting the le32/le64 targets (#98497)

This is a revert of ef5e7f90ea4d5063ce68b952c5de473e610afc02 which was a
temporary partial revert of 77ac823fd285973cfb3517932c09d82e6a32f46d.
The le32 and le64 targets are no longer necessary to retain, so this
removes them entirely.

show more ...

[CUDA][HIP][NFC] add CodeGenModule::shouldEmitCUDAGlobalVar (#98543)

Extract the logic whether to emit a global var based on CUDA/HIP
host/device related attributes to CodeGenModule::shouldEmitCUDA

[CUDA][HIP][NFC] add CodeGenModule::shouldEmitCUDAGlobalVar (#98543)

Extract the logic whether to emit a global var based on CUDA/HIP
host/device related attributes to CodeGenModule::shouldEmitCUDAGlobalVar
to be used by other places.

show more ...

[Coverage] Suppress covmap and profdata for system headers. (#97952)

With `system-headers-coverage=false`, functions defined in system
headers were not instrumented but corresponding covmaps were e

[Coverage] Suppress covmap and profdata for system headers. (#97952)

With `system-headers-coverage=false`, functions defined in system
headers were not instrumented but corresponding covmaps were emitted. It
caused wasting covmap and profraw.

This change improves:

- Reduce object size (due to reduced covmap)
- Reduce size of profraw (uninstrumented system headers occupied
counters)
- Smarter view of coverage report. Stubs of uninstrumented system
headers will be no longer seen.

show more ...

[PowerPC] Diagnose musttail instead of crash inside backend (#93267)

musttail is not often possible to be generated on PPC targets as when
calling to a function defined in another module, PPC needs

[PowerPC] Diagnose musttail instead of crash inside backend (#93267)

musttail is not often possible to be generated on PPC targets as when
calling to a function defined in another module, PPC needs to restore
the TOC pointer. To restore the TOC pointer, compiler needs to emit a
nop after the call to let linker generate codes to restore TOC pointer.
Tail call cannot generate expected call sequence for this case.

To avoid the crash inside the compiler backend, a diagnosis is added in
the frontend.

Fixes #63214

show more ...

[BPF] Fix linking issues in static map initializers (#91310)

When BPF object files are linked with bpftool, every symbol must be
accompanied by BTF info. Ensure that extern functions referenced by

[BPF] Fix linking issues in static map initializers (#91310)

When BPF object files are linked with bpftool, every symbol must be
accompanied by BTF info. Ensure that extern functions referenced by
global variable initializers are included in BTF.

The primary motivation is "static" initialization of PROG maps:

```c
extern int elsewhere(struct xdp_md *);

struct {
__uint(type, BPF_MAP_TYPE_PROG_ARRAY);
__uint(max_entries, 1);
__type(key, int);
__type(value, int);
__array(values, int (struct xdp_md *));
} prog_map SEC(".maps") = { .values = { elsewhere } };
```

BPF backend needs debug info to produce BTF. Debug info is not
normally generated for external variables and functions. Previously, it
was solved differently for variables (collecting variable declarations
in ExternalDeclarations vector) and functions (logic invoked during
codegen in CGExpr.cpp).

This patch generalises ExternalDefclarations to include both function
and variable declarations. This change ensures that function references
are not missed no matter the context. Previously external functions
referenced in constant expressions lacked debug info.

show more ...

[OpenCL] Emit opencl.cxx.version metadata for C++ (#92140)

Currently there is no way to tell whether an IR module was generated
using `-cl-std=cl3.0` or `-cl-std=clc++2021`, i.e., whether the origi

[OpenCL] Emit opencl.cxx.version metadata for C++ (#92140)

Currently there is no way to tell whether an IR module was generated
using `-cl-std=cl3.0` or `-cl-std=clc++2021`, i.e., whether the origin
was a OpenCL C or C++ for OpenCL source.

Add new `opencl.cxx.version` named metadata when compiling C++. Keep the
`opencl.ocl.version` metadata to convey the compatible OpenCL C version.

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

show more ...

[clang][Driver] Add HIPAMD Driver support for AMDGCN flavoured SPIR-V (#95061)

This patch augments the HIPAMD driver to allow it to target AMDGCN
flavoured SPIR-V compilation. It's mostly straightf

[clang][Driver] Add HIPAMD Driver support for AMDGCN flavoured SPIR-V (#95061)

This patch augments the HIPAMD driver to allow it to target AMDGCN
flavoured SPIR-V compilation. It's mostly straightforward, as we re-use
some of the existing SPIRV infra, however there are a few notable
additions:

- we introduce an `amdgcnspirv` offload arch, rather than relying on
using `generic` (this is already fairly overloaded) or simply using
`spirv` or `spirv64` (we'll want to use these to denote unflavoured
SPIRV, once we bring up that capability)
- initially it is won't be possible to mix-in SPIR-V and concrete AMDGPU
targets, as it would require some relatively intrusive surgery in the
HIPAMD Toolchain and the Driver to deal with two triples
(`spirv64-amd-amdhsa` and `amdgcn-amd-amdhsa`, respectively)
- in order to retain user provided compiler flags and have them
available at JIT time, we rely on embedding the command line via
`-fembed-bitcode=marker`, which the bitcode writer had previously not
implemented for SPIRV; we only allow it conditionally for AMDGCN
flavoured SPIRV, and it is handled correctly by the Translator (it ends
up as a string literal)

Once the SPIRV BE is no longer experimental we'll switch to using that
rather than the translator. There's some additional work that'll come
via a separate PR around correctly piping through AMDGCN's
implementation of `printf`, for now we merely handle its flags
correctly.

show more ...

[clang][AArch64][FMV] Stop emitting alias to ifunc. (#96221)

Long story short the interaction of two optimizations happening in
GlobalOpt results in a crash. For more details look at the issue
htt

[clang][AArch64][FMV] Stop emitting alias to ifunc. (#96221)

Long story short the interaction of two optimizations happening in
GlobalOpt results in a crash. For more details look at the issue
https://github.com/llvm/llvm-project/issues/96197. I will be fixing this
in GlobalOpt but it is a conservative solution since it won't allow us
to optimize resolvers which return a pointer to a function whose
definition is in another TU when compiling without LTO:

```
__attribute__((target_version("simd"))) void bar(void);
__attribute__((target_version("default"))) void bar(void);
int foo() { bar(); }
```

fixes: #96197

show more ...

[clang] Fix loss of `dllexport` for exported template specialization (#94664)

When dropping DLL attributes, ensure that the most recent declaration is
being checked.

[ARM] r11 is reserved when using -mframe-chain=aapcs (#86951)

When using the -mframe-chain=aapcs or -mframe-chain=aapcs-leaf options,
we cannot use r11 as an allocatable register, even if
-fomit-f

[ARM] r11 is reserved when using -mframe-chain=aapcs (#86951)

When using the -mframe-chain=aapcs or -mframe-chain=aapcs-leaf options,
we cannot use r11 as an allocatable register, even if
-fomit-frame-pointer is also used. This is so that r11 will always point
to a valid frame record, even if we don't create one in every function.

show more ...

[Clang] Prevent null pointer dereference in target attribute mangling (#94228)

This patch adds assertions in the getMangledNameImpl() function to
ensure that the expected target attributes (TargetA

[Clang] Prevent null pointer dereference in target attribute mangling (#94228)

This patch adds assertions in the getMangledNameImpl() function to
ensure that the expected target attributes (TargetAttr,
TargetVersionAttr, and TargetClonesAttr) are not null before they are
passed to appendAttributeMangling() to prevent potential null pointer
dereferences and improve the robustness of the attribute mangling
process.

This assertion will trigger a runtime error with a clear message in
debug build if any of the expected attributes are missing, facilitating
early and easier diagnosis and debugging of such issues related to
attribute mangling.

show more ...

[CodeGen] Remove useless zero-index constant GEPs (NFCI)

Remove zero-index constant expression GEPs, which are not needed
with opaque pointers and will get folded away.

[C++20] [Modules] Don't generate the defintition for non-const available external variables (#93530)

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

The root cause of the problem is, we m

[C++20] [Modules] Don't generate the defintition for non-const available external variables (#93530)

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

The root cause of the problem is, we mark the variable from other
modules as constnant in LLVM incorrectly. This patch fixes this problem
by not emitting the defintition for non-const available external
variables. Since the non const available externally variable is not
helpful to the optimization.

show more ...

[clang][FMV] Allow declaration of function versions in namespaces. (#93044)

Fixes the following bug:

namespace Name {
int __attribute((target_version("default"))) foo() { return 0; }
}

names

[clang][FMV] Allow declaration of function versions in namespaces. (#93044)

Fixes the following bug:

namespace Name {
int __attribute((target_version("default"))) foo() { return 0; }
}

namespace Name {
int __attribute((target_version("sve"))) foo() { return 1; }
}

int bar() { return Name::foo(); }

error: redefinition of 'foo'
int __attribute((target_version("sve"))) foo() { return 1; }

note: previous definition is here
int __attribute((target_version("default"))) foo() { return 0; }

While fixing this I also found that in the absence of default version
declaration, the one we implicitly create has incorrect mangling if
we are in a namespace:

namespace OtherName {
int __attribute((target_version("sve"))) foo() { return 2; }
}

int baz() { return OtherName::foo(); }

In this example instead of creating a declaration for the symbol
@_ZN9OtherName3fooEv.default we are creating one for the symbol
@_Z3foov.default (the namespace mangling prefix is omitted).
This has now been fixed.

show more ...

[clang] Fix crash passing function pointer without prototype. (#90255)

Fixes use-after-free iterating over the uses of the function.

Closes #88917

[Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (#88182)

At the moment, Clang is rather liberal in assuming that 0 (and by extension unqualified) is always a safe default. Th

[Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (#88182)

At the moment, Clang is rather liberal in assuming that 0 (and by extension unqualified) is always a safe default. This does not work for targets that actually use a different value for the default / generic AS (for example, the SPIRV that obtains from HIPSPV or SYCL). This patch is a first, fairly safe step towards trying to clear things up by querying a modules' default AS from the target, rather than assuming it's 0, alongside fixing a few places where things break / we encode the 0 == DefaultAS assumption. A bunch of existing tests are extended to check for non-zero default AS usage.

show more ...

[AArch64][PAC][clang][ELF] Support PAuth ABI core info (#85235)

Depends on #87545

Emit PAuth ABI compatibility tag values as llvm module flags:
- `aarch64-elf-pauthabi-platform`
- `aarch64-elf-

[AArch64][PAC][clang][ELF] Support PAuth ABI core info (#85235)

Depends on #87545

Emit PAuth ABI compatibility tag values as llvm module flags:
- `aarch64-elf-pauthabi-platform`
- `aarch64-elf-pauthabi-version`

For platform 0x10000002 (llvm_linux), the version value bits correspond
to the following LangOptions defined in #85232:

- bit 0: `PointerAuthIntrinsics`;
- bit 1: `PointerAuthCalls`;
- bit 2: `PointerAuthReturns`;
- bit 3: `PointerAuthAuthTraps`;
- bit 4: `PointerAuthVTPtrAddressDiscrimination`;
- bit 5: `PointerAuthVTPtrTypeDiscrimination`;
- bit 6: `PointerAuthInitFini`.

---------

Co-authored-by: Ahmed Bougacha <ahmed@bougacha.org>

show more ...

[CodeGen][i386] Move -mregparm storage earlier and fix Runtime calls (#89707)

When building the Linux kernel for i386, the -mregparm=3 option is
enabled. Crashes were observed in the sanitizer hand

[CodeGen][i386] Move -mregparm storage earlier and fix Runtime calls (#89707)

When building the Linux kernel for i386, the -mregparm=3 option is
enabled. Crashes were observed in the sanitizer handler functions, and
the problem was found to be mismatched calling convention.

As was fixed in commit c167c0a4dcdb ("[BuildLibCalls] infer inreg param
attrs from NumRegisterParameters"), call arguments need to be marked as
"in register" when -mregparm is set. Use the same helper developed there
to update the function arguments.

Since CreateRuntimeFunction() is actually part of CodeGenModule, storage
of the -mregparm value is also moved to the constructor, as doing this
in Release() is too late.

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

show more ...

[RISCV] Split code that tablegen needs out of RISCVISAInfo. (#89684)

This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.

This will allow

[RISCV] Split code that tablegen needs out of RISCVISAInfo. (#89684)

This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.

This will allow us to generate part of RISCVISAInfo.cpp using tablegen.

show more ...

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

Recommit
https://github.com/llvm/llvm-project/commit/1ecbab56dcbb78268c8d19af34a50591f90b12a0

Close https://git

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

Recommit
https://github.com/llvm/llvm-project/commit/1ecbab56dcbb78268c8d19af34a50591f90b12a0

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

The new thing in this commit is to allow to import the function body
from instantiations if it is marked with always-inline. See the
discussion in https://github.com/llvm/llvm-project/issues/86893 for
details.

show more ...