[Driver] Allow XRay on Apple Silicon

Codegen can handle XRay for AArch64, tell the driver to allow it.

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

[BOLT] Set IsRelro section attribute based on PT_GNU_RELRO segment

Handle PT_GNU_RELRO segment in accordance with Linux Standard Base spec
chapter 12:

> PT_GNU_RELRO
> The array element specifies the location and size of a segment which may
> be made *read-only* after relocations have been processed.

Perform a readelf-style mapping check between this segment and sections,
set `IsRelro` section attribute.

Reviewed By: #bolt, maksfb

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

[Driver] Allow XRay for more architectures on ELF systems

Codegen OS-agnostic for ELF and the runtime is mostly OS-agnostic. It
seems unnecessary to make restriction.

While here, rewrite test/Driver/XRay/xray-instrument*.c to be more conventional:
specify --target= explicitly instead of relying on the configured default target
(which needs `REQUIRES:`).

I am not sure enumerating every supported architecture is useful, so we just test a few.

Revert "[llvm-exegesis] Introduce Subprocess Executor Mode"

This reverts commit 0d4ef4ff01addbb40b9122a00d6b2f23104cbb3b.

This was causing build failures on certain platforms when built with
-Werror due to unused variable warnings in addition to causing build
failures on Linux systems with older kernel versions as kernels prior to
v5.15 don't support sys_pidfd_getpid. Reverting as I need to setup a
system to properly test the rest of the patches in this series.

Also reverts 8c6668fa42dba59ddc286ba256d71c1b9c5228b8 which fixed the
first issue so that the patch can actually be reverted.

[llvm-exegesis] Fix -Wunused-variable in BenchmarkRunner.cpp (NFC)

/data/llvm-project/llvm/tools/llvm-exegesis/lib/BenchmarkRunner.cpp:275:9: error: unused variable 'ParentPIDFD' [-Werror,-Wunused-variable]
    int ParentPIDFD = syscall(SYS_pidfd_open, ParentPID, 0);
        ^
1 error generated.

Convert MLIR IndentedOstream to header only.

This class has been causing me no end of grief for a long time, and the way it is used by mlir-tblgen is technically an ODR violation in certain situations.

Due to the way that the build is layered, it is important that the MLIR tablegen libraries only depend on the LLVM tablegen libraries, not on anything else (like MLIRSupport). It has to be this way because these libraries/binaries are special and must pre-exist the full shared libraries. Therefore, the dependency chain must be clean (and static).

At some point, someone pulled out a separate build target for just IndendedOstream in an attempt to satisfy the constraint. But because it is weird in different ways, this target was never installed properly as part of distributions, etc -- this causes problems for downstreams seeking to build a tblggen binary that doesn't itself have ODR/shared library problems.

I was attempting to fix the distribution stuff but just opted to collapse this into a header-only library and not try to solve this with build layering. I think this is the safest and the least bad thing for such a dep. This also makes for a clean comment that actually explains the constraint (which I was having trouble verbalizing with the weird subset dependency).

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

[llvm-exegesis] Introduce Subprocess Executor Mode

This patch introduces the subprocess executor mode. Currently, this new
mode doesn't do anything fancy, just executing the same code that the
inprocess executor would do, but within a subprocess. This sets up the
ability to add in many more memory-related features in the future.

Reviewed By: courbet

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

ValueTracking: Ignore -0 for nsz sqrt with UseInstrInfo in computeKnownFPClass

This avoids a regression when SignBitMustBeZero is moved to computeKnownFPClass.

[test] Regenerate test checks

[llvm-exegesis] Add ability to assign perf counters to specific PID

This patch gives the ability to assign performance counters within
llvm-exegesis to a specific process by passing its PID. This is needed
later on for implementing a subprocess executor. Defaults to zero, the
current process, for the InProcessFunctionExecutorImpl.

Reviewed By: courbet

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

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

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

[llvm-exegesis] Refactor FunctionExecutorImpl and create factory

In order to better support adding in new implementations of
FunctionExecutor, this patch makes some small changes so that it is
easier to add new ones in. FunctionExecutorImpl is renamed to
InProcessFunctionExecutorImpl to better reflect how it will be placed
relative to the soon-to-be introduced subprocess executor and a new
function is created to create executors so selection can be done more
easily. In addition, a new CLI flag, -execution-mode, which can be used
to select between the different executors.

Reviewed By: courbet

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

[lldb][Android] Add platform.plugin.remote-android.package-name

When LLDB fails to pull file from a package directory due to security
constraint, user needs to set the package name to
'platform.plugin.remote-android.package-name' property to run shell commands
as the package user. (e.g. to get file with 'cat' and 'dd').

https://cs.android.com/android/platform/superproject/+/master:
system/core/run-as/run-as.cpp;l=39-61;
drc=4a77a84a55522a3b122f9c63ef0d0b8a6a131627

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

[lldb][Android] Add PlatformAndroidTest

To test D152759 [lldb][Android] Support zip .so file

introduce PlatformAndroidTest with the capability of mocking adb client.

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

[mlir][sparse][gpu] extend SDDMM gpu test

Reviewed By: K-Wu

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

[lsan] Remove use_tls=0 from a few tests

The Objective-C runtime now stashes some state in TLS so any
test that indirectly initializes an Objective-C object will
have false positive leaks unless use_tls=1 as is the default.

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

[llvm-objcopy] -O binary: do not align physical addresses

llvm-objcopy should not insert padding before a section if its
physical addresses is not aligned to section's alignment. This
behavior will match GNU objcopy and is important for embedded images
where the physical address is used to store the initial data image.
The loader typically will copy this image using a start symbol
created by the linker. If llvm-objcopy inserts padding before such a
section, the symbol address will not match the location in the image.

This commit refines the change in https://reviews.llvm.org/D128961
which intended to align sections which type changed from NOBITS and
their offset may not be aligned. However, it affected all sections.

Fix https://github.com/llvm/llvm-project/issues/62636

Reviewed By: jhenderson, MaskRay

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

[gn build] Port 12dee9d3cd76

[lldb][Android] Support zip .so file

In Android API level 23 and above, dynamic loader is able to load .so file
directly from APK, which is zip file.
https://android.googlesource.com/platform/bionic/+/master/
android-changes-for-ndk-developers.md#
opening-shared-libraries-directly-from-an-apk

The .so file is page aligned and uncompressed, so
ObjectFileELF::GetModuleSpecifications works with .so file offset and size
directly from zip file without extracting it. (D152757)

GDBRemoteCommunicationServerCommon::GetModuleInfo returns a module spec to LLDB
with "zip_path!/so_path" file spec, which is passed through from Android
dynamic loader, and the .so file offset and size.

PlatformAndroid::DownloadModuleSlice uses 'shell dd' to download the .so file
slice from the zip file with the .so file offset and size.

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

[BOLT] Sort CallSiteInfo targets by symbol name in YAMLWriter

Align YAML and fdata profiles by sorting CallSiteInfo targets by symbol name,
aligning it to fdata. By default, YAML CallSiteInfo is sorted by function id,
which is the order of function in the binary.

Follow-up to D152731, aligning yaml vs fdata, and in turn all three between to
each other.

Reviewed By: #bolt, rafauler

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

[lldb][ObjectFileELF] Set ModuleSpec file offset and size

In Android API level 23 and above, dynamic loader is able to load .so file
directly from APK.
https://android.googlesource.com/platform/bionic/+/master/
android-changes-for-ndk-developers.md#
opening-shared-libraries-directly-from-an-apk

ObjectFileELF::GetModuleSpecifications will load a .so file, which is page
aligned and uncompressed, directly from a zip file. However it does not
set the .so file offset and size to the ModuleSpec. Also crc32 calculation
uses more data than the .so file size.

Set the .so file offset and size to the ModuleSpec, and set the size to
MapFileData length argument. For normal file, file_offset should be zero,
and length should be the size of the file.

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

Revert "[llvm-objcopy] -O binary: do not align physical addresses"

This reverts commit eb1442d0f73c76cfb5051d133f858fe760d189cf.

The test tools/llvm-objcopy/ELF/binary-paddr.test fails on
ppc64be-clang-test-suite:
https://lab.llvm.org/buildbot#builders/231/builds/13120

Reverting at author's request.

[SelectionDAG] Remove isNullValue and isAllOnesValue

These functions have been deprecated since:

  commit f271e5d9d44e833ef2264e5b0e9aa5f8383c173d
  Author: Kazu Hirata <kazu@google.com>
  Date:   Sun Mar 12 18:25:07 2023 -0700

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

Define/guard MLIR_STANDALONE_BUILD LLVM_LIBRARY_OUTPUT_INTDIR var.

It looks like MLIR is using the more modern CMAKE_LIBRARY_OUTPUT_DIRECTORY, but AddLLVM still uses this older LLVM specific alias.

In the specific case I was running into, the empty variable was causing `-Wl,-rpath-link,` on the command line, causing the following argument to be swallowed. This was maddening, because the following argument was the .o file containing `main` and I was getting `main` undefined errors when it was clearly there. This is egregious enough that I chose to guard it.

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

[Bazel][mlir] Fix after bba2b656110209a3d9863b92c060082479b06ab1

[clang][test] Refactor FileCheck metadata in pragma-followup_inner.cpp

- FileCheck variables for metadata are defined and referenced rather than
  repeatedly redefined.
- All numeric metadata identifiers are refactored to a FileCheck variable.

Reviewed By: MaskRay

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

[libc] Remove disabled pass after performance improvement

This pass used to cause huge compile time regressions, That has been
address and can now be re-added.

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

Fix MLIR test after 6eca120dd8d3e

[llvm-objcopy] -O binary: do not align physical addresses

llvm-objcopy should not insert padding before a section if its
physical addresses is not aligned to section's alignment. This
behavior will match GNU objcopy and is important for embedded images
where the physical address is used to store the initial data image.
The loader typically will copy this image using a start symbol
created by the linker. If llvm-objcopy inserts padding before such a
section, the symbol address will not match the location in the image.

This commit refines the change in https://reviews.llvm.org/D128961
which intended to align sections which type changed from NOBITS and
their offset may not be aligned. However, it affected all sections.

Fix https://github.com/llvm/llvm-project/issues/62636

Reviewed By: jhenderson, MaskRay

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

[libc++][NFC] clang-format filesystem_error.h

It's giving me trouble in an upcoming patch so I figured I'd do it as
a NFC before landing that other patch.

[UsersManual] Add llvm-progen as an alternative tool for AutoFDO profile generation.

I'm adding llvm-profgen as an alternative AutoFDO profile generator to the user manual. llvm-profgen is widely used and tested by META as their default profile generator.

Reviewed By: davidxl

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

[libc] Remove flexible array and replace with a template

Currently the implementation of the RPC interface requires a flexible
struct. This caused problems when compilling the RPC server with GCC as
would be required if trying to export the RPC server interface. This
required that we either move to the `x[1]` workaround or make it a
template parameter. While just using `x[1]` would be much less noisy,
this is technically undefined behavior. For this reason I elected to use
templates.

The downside to using templates is that the server code must now be able
to handle multiple different types at runtime. I was unable to find a
good solution that didn't rely on type erasure so I simply branch off of
the given value.

Reviewed By: JonChesterfield

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

Improve MLIR "view-op-graph" to color operations according to their name

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

Remove declaration for unimplemented function `function_interface_impl::getFunctionType`

Fix #63413

[Hexagon] Handle 64-bit operands when lowering ADDO/SUBO

[mlir][irdl] Add `irdl.attributes` operation for defining named attributes

This commit introduces the `irdl.attributes` operation, which allows defining named attributes for the parent operation. Each attribute is defined with a name and a type constraint.

Example usage:
```
irdl.dialect @example {
  irdl.operation @attr_op {
    %0 = irdl.any
    %1 = irdl.is i64
    irdl.attributes {
      "attr1" = %0,
      "attr2" = %1
    }
  }
}
```
In this example the operation will expect an arbitrary attribute "attr1"
and an attribute "attr2" with value `i64`.

Reviewed By: math-fehr, Mogball

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

Revert "Fix mlir windows buildbot after ec146cb7c0b4"

This reverts commit 46c2e1fdb3065542bed96ba944ae4a58465d2b5e.

The fix was already landed in 51e917d4af.

[mlir][RunnerUtils] Make symbols private + implement loading mechanism.

There are two ways to make symbols from a shared library visible in the
execution engine: exporting the symbols with public visibility or
implementing a loading/unloading mechansim that registers the exported
symbols explicitly. The latter has only been available in the JIT runner
until recently, but https://reviews.llvm.org/D153029 makes it available
in any usage of the execution engine (including the Python bindings).

This patch makes the runner utils library use the latter mechanism
instead of the former, i.e., it makes all of its symbols private and
implements the init/destroy functions of the loading mechanism to
control explicitly which symbols it registers.

Reviewed By: mehdi_amini

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

[mlir][async] Mark exported symbols of runtime lib as visible.

The async runtime library explicitly registers the symbols it exports
with the loading mechanism of the execution engine. This even works even
though these symbols were marked as hidden in the library. However, if
used outside the execution engine, such as with `lli --dlopen` or if AOT
compiled, these hidden symbols would not be found. This patch thus marks
all symbols that are part of the API as visible.

Reviewed By: mehdi_amini

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

Fix mlir windows buildbot after ec146cb7c0b4

ec146cb7c0b4 added two new ReducKinds for float maximum and minimum
(along with support in loop vectorizer).

Enumerate these kinds in SLPVectorizer to fix mlir windows build bot
errors:

C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Vectorize\SLPVectorizer.cpp(13883): error C2220: the following warning is treated as an error
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Vectorize\SLPVectorizer.cpp(13883): warning C4062: enumerator 'llvm::RecurKind::FMinimum' in switch of enum 'llvm::RecurKind' is not handled

[Docs] Update llvm-test-suite PGO instructions to use LLVM IR PGO by
default.

- Currently, the default instructions will use Clang's frontend PGO
  feature.

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

[AMDGPU] Simplify BlockInfo in SIInsertWaitcnts. NFC.

[libc++] Make sure our .clang-format is used for all languages

In particular, this ensures that it is used for Objective-C and
Objective-C++, since we have a few files that get detected as that.

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

[OpenMP] Disable some tests for AArch64

Like for X86, some of the tests also need to be disabled for AArch64.

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

[libc] Fix libmath test compilation when using UInt<T>

This patch:
(1) adds the add_with_carry_const and sub_with_borrow_const constexpr calls
to add and sub, respectively. Both add and sub are constexpr calls and
were call the non-constexpr version of add/sub_with_borrow.
(2) adds explicit UIntType construct calls in some fp tests.

Reviewed By: lntue

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

[scudo] Finer lock granularity in Region of SizeClassAllocator64

In this CL, we introduce two new locks, MMLock for MemMap operations and
FLLock for freelist operations.

MMLock will be used when we want to manipulate pages. For example,
mapping more pages through populateFreeList() and releaseToOSMaybe().

FLLock will be used when we want to access the freelist. For example,
pushBlocks() and popBatch().

With the new locks, they increase the parallelism of the operations
mentioned above. For example, populateFreeList() won't block the
pushBlocks() when it's still doing the system call for more pages.

We also enforce lock hierarchy to avoid deadlock, MMLock is required to
be held before FLLock if you have to lock both of them. We don't store
the lock owner, therefore, we rely static thread-safey annotation to
detect any violation.

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

[DebugInfo] Fix emission of empty debug_names for Apple

D118754 added a new DICompileUnit::DebugNameTableKind for "Apple", so that,
under DWARF 5, the following combination is used inside DwarfDebug.cpp:

```
(lldb) p getAccelTableKind()
(llvm::AccelTableKind) $6 = Dwarf
(lldb) p CU.getNameTableKind()
(llvm::DICompileUnit::DebugNameTableKind) $7 = Apple
```

This creates a problem in the if statements changed, whereby "for non Apple
AccelTableKind" we emit empty tables for any DebugNameTableKind that is not
"Default". We should consider the newly added kind here too.

Note that our existing test could have caught this, if only it had checked the
_contents_ of the table, instead of merely checking for the existence of the
section.

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

[DebugInfo][NFC] Remove dead lines of test input

This test uses a separate input file, so its IR is meaningless.

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

[gn build] Port 7c8365121a7d

[RISCV] Model vxrm control for vsmul, vssra, vssrl, vnclip, and vnclipu

Depends on D151397.

This patch follows the patch-set of D151395. This patch seeks to
update all the remaining fixed-point intrinsics to model vxrm
control, adding rounding mode control for `vsmul`, `vssra`,
`vssrl`, `vnclip`, and `vnclipu`.

Reviewed By: craig.topper

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

[3/3][RISCV][POC] Model vxrm in C intrinsics for RVV fixed-point instruction vaadd, vasub

Depends on D151396.

This is the 3rd patch of the patch-set. For the cover letter of the
patch-set, please checkout D151395.

This commit consists of change in both clang front-end and RISC-
back-end.

In the front-end, this commit adds an additional operand to the C
intrinsics of `vaadd`, `vaaddu`, `vasub`, and `vasubu`, that models
the control of the rounding mode.

In the back-end, using `vaadd` as an example, this commit replaces the
existing `int.riscv.vaadd.*` with `int.riscv.vaadd.rm.*` that was
introduced in the previous patch, with the extra operand that models
the control of the rounding mode (`vxrm`) for RVV fixed-point
intrinsics.

Note: The first 3 commit of the patch-set shows the intent to model the
rounding mode for fixed-point intrinsics by applying change to
`vaadd`, `vaaddu`, `vasub`, and `vasubu`. The proceeding patch will
apply the change to the rest of the other fixed-point instructions.

Reviewed By: craig.topper

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

[2/3][RISCV][POC] Model vxrm in LLVM intrinsics and machine instructions for RVV fixed-point instructions

Depends on D151395.

This is the 2nd patch of the patch-set. For the cover letter of the
patch-set, please checkout D151395. This patch originates from
D121376.

This commit models vxrm by adding an immediate operand into intrinsics
and machine instructions of RVV fixed-point instruction `vaadd`,
`vaaddu`, `vasub`, and `vasubu`. This commit only covers intrinsics of
the four instructions, the proceeding patches of the patch-set will do
the same to other RVV fixed-point instructions.

The current naiive approach is to have a write to vxrm inserted before
every fixed-point instruction. This is done by the new added pass
`RISCVInsertReadWriteCSR`. The reason to name the pass in a more general
term is because we will also model rounding mode for the RVV floating-
point instructions. The approach will be improved in the future,
implementing partial redundancy elimination algorithms to it.

The original LLVM intrinsics and machine instructions, take `vaadd` as
an example, does not model the rounding mode is not removed in this
patch. That is, `int.riscv.vaadd.*` co-exists with
`int.riscv.vaadd.rm.*` after this patch. The next patch will add C
intrinsics of vaadd with an additional operand that models the control
of the rounding mode, in this patch, `int.riscv.vaadd.rm.*` will
replace `int.riscv.vaadd.*`.

Authored-by: ShihPo Hung <shihpo.hung@sifive.com>
Co-Authored-by: eop Chen <eop.chen@sifive.com>
Reviewed By: craig.topper

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

[mlir][Transform] Allow parameter and value types in merge_handles op

Similar to operation handles, merging handles for other types can be useful to
avoid repetition of common transformations across a set of parameters.
For example, forming a list of static values for comparison rather than
comparing the parameters one at a time.

Reviewed By: ftynse

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

[SLP] Silence -Wswitch warning after ec146cb7c0b4a162ee73463e6c7bb306b99e013b

{min,max}imum(X, X) is X so we can take the same path as min/max.

[clangd] Use resolveTypeToRecordDecl() to resolve the type of a base specifier during heuristic resolution

The code for resolving the type of a base specifier was inside
CXXRecordDecl::lookupDependentName(), so this patch reimplements
lookupDependentName() in HeuristicResolver.

Fixes https://github.com/clangd/clangd/issues/1657

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

[chrono][test] Fixes some tests on Windows.

The tests switched from assert to TEST_EQUAL to make it easier to debug
assertion failures. This is used to fix most tests on Windows.

Some CI tests give no output, which needs to be investigated separately.

Reviewed By: #libc, ldionne

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

[libc++][format] Removes an AIX work-around.

This work-around was for Clang 13 and older, which we no longer support.

Reviewed By: #libc, ldionne

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

[libc++][test] Removes old fallbacks.

All supported compilers support the -std=year except Clang < 17 which
doesn't support C++23. This fallback is marked for removal once we no
longer support Clang 16.

Reviewed By: #libc, ldionne

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

[libc++][format] Fixes UTF-8 continuation.

The mask used to check whether a code unit is a valid continuation was
incorrect and accepts non-continuation code points. This fixes the
issue.

Reviewed By: ldionne, tahonermann, #libc

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

[libc++][CI] Install newer CMake version.

This version allowed testing the std module in C++26 mode.

Reviewed By: #libc, ldionne

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

[LV] Add support for minimum/maximum intrinsics

{mini|maxi}mum intrinsics are different from {min|max}num intrinsics in
the propagation of NaN and signed zero. Also, the minnum/maxnum
intrinsics require the presence of nsz flags to be valid reductions in
vectorizer. In this regard, we introduce a new recurrence kind and also
add support for identifying reduction patterns using these intrinsics.

The reduction intrinsics and lowering was introduced here: 26bfbec5d2.

There are tests added which show how this interacts across chains of
min/max patterns.

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

[lld] Make lit files relocatable

2700da5fe28d8 added lld/test/Unit/lit.site.cfg.py.in in a state
that half-supports relocatable lld lit tests.

Make them fully relocatable.

See description of fb80b6b2d58c47 for background.

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

AMDGPU: Delete old AMDGPUPropagateAttributes pass

The optimizing, non-broken features have all been moved to
AMDGPUAttributor. The only remaining piece of functionality was the
broken propagation of the wavesize features. This was fundamentally
broken and a hack for device library linking. It doesn't matter when
the device libraries are correctly linked and internalized.

In case of linked-as-normal-bitcode (as comgr still does), we're
reliant on the global subtarget anyway. If we can get away without
forcing target-cpu, we should just as well be able to get away without
propagating target-features.

[AIX][TLS] Generate 32-bit local-exec access code sequence

This patch adds support for the TLS local-exec access model on AIX to allow
for the ability to generate the 32-bit (specifically, non-optimized) code sequence.
This work is a follow up of D149722.

The particular sequence that is generated for this sequence is as follows:
```
.tc var[TC],var[TL]@le.   // variable offset, with the le relocation specifier

bla .__get_tpointer()     // get the thread pointer, modifies r3
lwz reg1, var[TC](2)      // load the variable offset
add reg2, r3, reg1        // add the variable offset to the retrieved thread pointer
```

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

[RISCV] Remove mask from vrgatherei16 in lowerVECTOR_INTERLEAVE.

Unless I'm missing something we need to update the whole vector
not just where OddMask is true.

Reviewed By: luke

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

Revert "[lld][Arm] Big Endian - Byte invariant support."

This reverts commit 8cf8956897ce9bca3176c6339077b1ca17b27abc.

InlineSpiller: Consider copy bundles when looking for snippet copies

This was looking for full copies produced by SplitKit, but SplitKit
introduces copy bundles if not all lanes are live. The scan for uses
needs to look at bundles, not individual instructions.

This is a prerequisite to avoiding some redundant spills due to
subregisters which will help avoid an allocation failure in a future
patch.

llvm-reduce: Fix introducing invalid uses of intrinsics

[AArch64][SME] Rename strided load/store enums

This patch renames load/store enums to be equivalent
to the contiguous addressing modes with _STRIDED and _STRIDED_IMM
suffixed.

[Attributor] Convert test to opaque pointers (NFC)

[Attributor] Name instructions in test (NFC)

[Attributor] Convert some tests to opaque pointers (NFC)

[clang-format] Add InsertNewlineAtEOF to .clang-format files

Also, reformat all clang-format related files.

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

[libc++] Add missing [[maybe_unused]] attribute in format tests

Otherwise, Clang complains about format_ctx being unused in the tests
when exceptions are disabled in Freestanding mode. I don't know why it
doesn't complain not in freestanding mode.

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

[LoopVersioning] Convert tests to opaque pointers (NFC)

[LoopVersioning] Regenerate test checks (NFC)

[NFC][libc++] Addresses LWG3927.

Changes to preconditions have no impact on the library.

Implements
- LWG3927 Unclear preconditions for operator[] for sequence containers

Reviewed By: #libc, philnik

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

[NFC][libc++] Addresses LWG3935.

Note libc++ implemented this in its initial version.

Implements
- LWG3935 template<class X> constexpr complex& operator=(const complex<X>&) has no specification

Reviewed By: #libc, philnik, ldionne

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

[SafepointIRVerifier] Convert test to opaque pointers (NFC)

[DAG] Add getExtOrTrunc helper. NFC.

Wrap the getSExtOrTrunc/getZExtOrTrunc calls behind an IsSigned argument.

[LTO] Avoid -opaque-pointers=0 in test (NFC)

Commit the bitcode file instead of generating it dynamically, as
this will no longer be possible in the future.

[libc++] Add incomplete availability markup for std::pmr

This fixes rdar://110330781, which asked for the feature-test macro
for std::pmr to take into account the deployment target. It doesn't
fix https://llvm.org/PR62212, though, because the availability markup
itself must be disabled until some Clang bugs have been fixed.

This is pretty vexing, however at least everything should work once
those Clang bugs have been fixed. In the meantime, this patch at least
adds the required markup (as disabled) and ensures that the feature-test
macro for std::pmr is aware of the deployment target requirement.

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

[DebugInfo] Convert tests to opaque pointers (NFC)

[Bitcode] Remove -opaque-pointer=0 check lines (NFC)

These tests were testing both typed an opaque pointers. Only keep
opaque pointers tests.

[llvm-nm] Avoid -opaque-pointers option in test (NFC)

Commit the typed pointer bitcode file instead of producing it,
as this will not be possible in the future anymore.

[DAG] Fold (abds x, y) -> (abdu x, y) iff both args are known positive

This is a generic DAG combine version of D151055 which recognizes when a signed ABDS can be safely replaced with a unsigned ABDU instruction if it is legal.

Alive2: https://alive2.llvm.org/ce/z/pb5BjG

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

[AArch64] Use ISD::isExtOpcode. NFC

[AArch64] Try to fold uaddlv and uaddlp

Add tablegen pattern for uaddlv(uaddlp(x)) ==> uaddlv(x).

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

[AMDGPU] Remove unused method Waitcnt::dominates(). NFC

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

[LoongArch] Optimize conditional selection of integer

This patch optimizes code generation by leveraging the zeroing behavior of the `maskeqz`/`masknez` instructions.

```
int sel(int a, int b)
{
    return (a < b) ? a : 0;
}
```

```
slt $a1,$a0,$a1
masknez $a2,$r0,$a1
maskeqz $a0,$a0,$a1
or $a0,$a0,$a2
```

=>

```
slt $a1,$a0,$a1
maskeqz $a0,$a0,$a1
```

Reviewed By: SixWeining

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

[AMDGPU] Use verify<domtree> instead of intra-pass asserts.

Verifying dominator tree is expensive using intra-pass
asserts. Asserts added during D147408 are
increasing the build time of libc significantly. This change
does the verification after the atomic optimizer pass
and should fix the regression reported in D153232.

Reviewed By: arsenm, #amdgpu

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

[LoongArch] Indent LoongArchInstrInfo.td a little bit. NFC

[libc][math] Improve exp2f performance.

Re-organize special cases and add a special case when `|x| < 2^-5`.

Reviewed By: michaelrj

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

[libc][math] Slightly improve sinhf and coshf performance.

Re-order exceptional branches and slightly adjust the evaluation.
Depends on https://reviews.llvm.org/D153026 .

Reviewed By: michaelrj

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

[libc][math] Improve tanhf performance.

Re-order exceptional branches and slightly adjust the evaluation.

Performance tested with the CORE-MATH project on AMD EPYC 7B12 (clocks/op)

Reciprocal throughputs:
```
--- BEFORE ---

$ CORE_MATH_PERF_MODE=rdtsc ./perf.sh tanhf
[####################] 100 %  (with -mavx2 -mfma)
Ntrial = 20 ; Min = 7.794 + 0.102 clc/call; Median-Min = 0.066 clc/call; Max = 8.267 clc/call;
[####################] 100 %. (with -msse4.2)
Ntrial = 20 ; Min = 10.783 + 0.172 clc/call; Median-Min = 0.144 clc/call; Max = 11.446 clc/call;
[####################] 100 %. (SSE2)
Ntrial = 20 ; Min = 18.926 + 0.381 clc/call; Median-Min = 0.342 clc/call; Max = 19.623 clc/call;

--- AFTER ---

$ CORE_MATH_PERF_MODE=rdtsc ./perf.sh tanhf
[####################] 100 %  (with -mavx2 -mfma)
Ntrial = 20 ; Min = 6.598 + 0.085 clc/call; Median-Min = 0.052 clc/call; Max = 6.868 clc/call;
[####################] 100 %  (with -msse4.2)
Ntrial = 20 ; Min = 9.245 + 0.304 clc/call; Median-Min = 0.248 clc/call; Max = 10.675 clc/call;
[####################] 100 %. (SSE2)
Ntrial = 20 ; Min = 11.724 + 0.440 clc/call; Median-Min = 0.444 clc/call; Max = 12.262 clc/call;
```

Latency:
```
--- BEFORE ---

$ PERF_ARGS="--latency" CORE_MATH_PERF_MODE=rdtsc ./perf.sh tanhf
[####################] 100 %  (with -mavx2 -mfma)
Ntrial = 20 ; Min = 38.821 + 0.157 clc/call; Median-Min = 0.122 clc/call; Max = 39.539 clc/call;
[####################] 100 %. (with -msse4.2)
Ntrial = 20 ; Min = 44.767 + 0.766 clc/call; Median-Min = 0.681 clc/call; Max = 45.951 clc/call;
[####################] 100 %. (SSE2)
Ntrial = 20 ; Min = 55.055 + 1.512 clc/call; Median-Min = 1.571 clc/call; Max = 57.039 clc/call;

--- AFTER ---

$ PERF_ARGS="--latency" CORE_MATH_PERF_MODE=rdtsc ./perf.sh tanhf
[####################] 100 %  (with -mavx2 -mfma)
Ntrial = 20 ; Min = 36.147 + 0.194 clc/call; Median-Min = 0.181 clc/call; Max = 36.536 clc/call;
[####################] 100 %  (with -msse4.2)
Ntrial = 20 ; Min = 40.904 + 0.728 clc/call; Median-Min = 0.557 clc/call; Max = 42.231 clc/call;
[####################] 100 %. (SSE2)
Ntrial = 20 ; Min = 55.776 + 0.557 clc/call; Median-Min = 0.542 clc/call; Max = 56.551 clc/call;
```

Reviewed By: michaelrj

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

[LoongArch] Add missing chains and remove unnecessary `SDNPSideEffect` property for some intrinsic nodes

[AArch64] Add tablegen patterns for fp16 fcvtn2.

Similar to the existing f32 pattern, this adds a tablegen pattern for the fp16
fcvtn2.

[lld][Arm] Big Endian - Byte invariant support.

Arm has BE8 big endian configuration called a byte-invariant(every byte has the same address on little and big-endian systems).

When in BE8 mode:
  1. Instructions are big-endian in relocatable objects but
     little-endian in executables and shared objects.
  2. Data is big-endian.
  3. The data encoding of the ELF file is ELFDATA2MSB.

To support BE8 without an ABI break for relocatable objects,the linker takes on the responsibility of changing the endianness of instructions. At a high level the only difference between BE32 and BE8 in the linker is that for BE8:
  1. The linker sets the flag EF_ARM_BE8 in the ELF header.
  2. The linker endian reverses the instructions, but not data.

This patch adds BE8 big endian support for Arm. To endian reverse the instructions we'll need access to the mapping symbols. Code sections can contain a mix of Arm, Thumb and literal data. We need to endian reverse Arm instructions as words, Thumb instructions
as half-words and ignore literal data.The only way to find these transitions precisely is by using mapping symbols. The instruction reversal will need to take place after relocation. For Arm BE8 code sections (Section has SHF_EXECINSTR flag ) we inserted a step after relocation to endian reverse the instructions. The implementation strategy i have used here is to write all sections BE32  including SyntheticSections then endian reverse all code in InputSections via mapping symbols.

Reviewed By: peter.smith

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

[LinkerWrapper] Support linking vendor bitcode late

The GPU vendors currently provide bitcode files for their device
runtime. These files need to be handled specially as they are not built
to be linked in with a standard `llvm-link` call or through LTO linking.
This patch adds an alternative to use the existing clang handling of
these libraries that does the necessary magic to make this work.

We do this by causing the LTO backend to emit bitcode before running the
backend. We then pass this through to clang which uses the existing
support which has been fixed to support this by D152391. The backend
will then be run with the merged module.

This patch adds the `--builtin-bitcode=<triple>=file.bc` to specify a single
file, or just `--clang-backend` to let the toolchain handle its defaults
(currently nothing for NVPTX and the ROCm device libs for AMDGPU). This may have
a performance impact due to running the optimizations again, we could
potentially disable optimizations in LTO and only do the linking if this is an
issue.

This should allow us to resolve issues when relying on the `linker-wrapper` to
do a late linking that may depend on vendor libraries.

Depends on D152391

Reviewed By: JonChesterfield

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

[Clang] Allow bitcode linking when the input is LLVM-IR

Clang provides the `-mlink-bitcode-file` and `-mlink-builtin-bitcode`
options to insert LLVM-IR into the current TU. These are usefuly
primarily for including LLVM-IR files that require special handling to
be correct and cannot be linked normally, such as GPU vendor libraries
like `libdevice.10.bc`. Currently these options can only be used if the
source input goes through the AST consumer path. This patch makes the
changes necessary to also support this when the input is LLVM-IR. This
will allow the following operation:

```
clang in.bc -Xclang -mlink-builtin-bitcode -Xclang libdevice.10.bc
```

Reviewed By: yaxunl

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