[libc++][PSTL] Disable `-Wpass-failed`.

PSTL contains many pragmas that request loop vectorization, which would
produce a warning when the compiler is unable to fulfill the request (if
`-Wpass-failed` is enabled). This is normal and expected in some cases,
and we don't want `-Werror` to turn that into a compilation failure.

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

(cherry picked from commit 1d340250a894b6ec956e2145b2fc7babbf83e61b)

[SelectionDAG] Use TypeSize variant of ComputeValueVTs to compute correct offsets for scalable aggregate types.

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

[NFC][SelectionDAGBuilder] Use getObjectPtrOffset in place of discrete nodes.

Some prep work to make aggregate loads and stores TypeSize aware.

[SVE] Add test to show incorrect code generation for scalable vector struct loads and stores.

Patch also includes a minor fix to AArch64::isLegalAddressingMode
to ensure all scalable types have a suitable bailout.

[AArch64] Fix crash when neither Neon nor SVE are enabled

The subtarget was unconditionally reporting that SVE was to be used to
lower vectors when Neon was unavailable, even when SVE itself was
unavailable. This decision leads other parts of the compiler to crash,
e.g., when querying SVE vector sizes.

Reviewed By: sdesmalen

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

(cherry picked from commit c058eb998aa6fa89d412984d6cbf9e3f826249f3)

[WebAssembly][Objcopy] Write output section headers identically to inputs

Previously when objcopy generated section headers, it padded the LEB
that encodes the section size out to 5 bytes, matching the behavior of
clang. This is correct, but results in a binary that differs from the
input. This can sometimes have undesirable consequences (e.g. breaking
source maps).

This change makes the object reader remember the size of the LEB
encoding in the section header, so that llvm-objcopy can reproduce it
exactly. For sections not read from an object file (e.g. that
llvm-objcopy is adding itself), pad to 5 bytes.

Reviewed By: jhenderson

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

(cherry picked from commit 1b21067cf247c62c2442daa7ee2d3915249d1ee2)

[RISCV] Stop performFP_TO_INTCombine from folding with ISD::FRINT.

FRINT was added to matchRoundingOp after this function was written.
So FRINT was not tested originally.

For vectors, folding this causes us to create a CSR swap that tries
to write 7 to FRM. This is an illegal value and will cause the CSR
write to fail.

While this might be a legal fold we could do, I'm disabling it for
now so we can backport to LLVM 17 with the least risk.

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

(cherry picked from commit 2df9328fe3a0575fa415964a3c3544b0912b168e)

Reapply [CHR] Fix up phi nodes with unreachable predecessors (PR64594)

Relative to the previous attempt, this also adjusts RegionInfo
verification to allow unreachable predecessors.

-----

If a block in the CHR region has an unreachable predecessor, then
there will be no edge from that predecessor to the newly cloned
block. However, a phi node entry for it will be left behind. Make
sure that these incoming blocks get dropped as well.

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

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

(cherry picked from commit 7e2f1ae7e0ebc7e71ffaa865175aef27fae3b034)

Revert "[Profile] Remove duplicate file locks when enabled continuous mode and online merging."

This reverts commit 985486dca48bffd9e991d9f5ac32e1d109ae000f.

This seems to cause malformed profdata: crbug.com/1469456

(cherry picked from commit 4b08be77c98a4c15b8b3d634fab4ffc24bf4ef38)

Fix truncated __OPENMP_NVPTX__ preprocessor condition

I don't have a test case for this but noticed this warning when including system headers with `-I` rather than `-isystem`.

```
In file included from <built-in>:1:
In file included from /nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_runtime_wrapper.h:157:
/nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_math.h:39:25: warning: extra tokens at end of #ifdef directive [-Wextra-tokens]
                        ^
```

Reviewed By: tra

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

(cherry picked from commit c49142e4f5c8645a4d741d233f0cb55ef1ef87a2)

flang: Fix module-debug-file-loc-linux.f90 in standalone

In a standalone build, there is no guarantee that flang code would be
saved in a directory named flang. Check only the path under flang's root
directory.

Reviewed By: #flang, kiranchandramohan

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

(cherry picked from commit 94f377d880376fa6d5653430cad2777e51759d48)

[clang] Skip stores in init for fields that are empty structs

An empty struct is handled as a struct with a dummy i8, on all targets.

Most targets treat an empty struct return value as essentially
void - but some don't. (Currently, at least x86_64-windows-* and
powerpc64le-* don't treat it as void.)

When intializing a struct with such a no_unique_address member,
make sure we don't write the dummy i8 into the struct where there's
no space allocated for it.

Previously it would clobber the actual valid data of the struct.

Fixes https://github.com/llvm/llvm-project/issues/64253, and
possibly https://github.com/llvm/llvm-project/issues/64077
and https://github.com/llvm/llvm-project/issues/64427 as well.

We should omit the store for any empty record (not only ones
declared with no_unique_address); we can have a situation where a
class doesn't have the no_unique_address attribute, but is embedded
in an outer struct with the no_unique_address attribute - like this:

    struct S {};
    S f();
    struct S2 : public S { S2();};
    S2::S2() : S(f()) {}
    struct S3 { int x; [[no_unique_address]] S2 y; S3(); };
    S3::S3() : x(1), y() {}

Here, the problematic store (which this patch omits) is in
the constructor of S2. In the case of S3, S2 has no valid storage
and aliases x - thus the constructor of S2 should omit the dummy
store.

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

(cherry picked from commit d60c3d08e78dfbb4b180776b83e910d810e1f36a)

[RISCV] Add bounds check before use on returned iterator.

Check iterator validity before use; fixes a crash seen in the RISC-V
Zcmp Push/Pop optimization pass when compiling an internal benchmark.

Reviewed By: asb, wangpc

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

(cherry picked from commit 53e89f5e3f2cefa432f7262343654c2a582dcbe1)

[Driver] Default riscv*- triples to -fdebug-default-version=4

This adds a RISC-V special case to ToolChain::GetDefaultDwarfVersion,
affecting Linux/Haiku/RISCVToolChain.

DWARF v5 .debug_loclists/.debug_rnglists's
DW_LLE_offset_pair/DW_RLE_offset_pair entry kinds utilitize `.uleb128 A-B`
directives where A and B reference local labels in code sections.
When A and B are separated by a RISC-V linker-relaxable instruction,
A-B is incorrectly folded without a relocation, causing incorrect debug
information.

```
void ext(void);
int foo(int x) {ext(); return 0;}
// DW_AT_location [DW_FORM_loclistx] of a DW_TAG_formal_parameter references a DW_LLE_offset_pair that can be incorrect after linker relaxation.

int ext(void);
void foo() { {
  int ret = ext();
  if (__builtin_expect(ret, 0))
    ext();
} }
// DW_AT_ranges [DW_FORM_rnglistx] of a DW_TAG_lexical_block references a DW_RLE_offset_pair that can be incorrect after linker relaxation.
```

D157657 will implement R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128
relocations, fixing the issue, but the relocation is only supported by
bleeding-edge binutils 2.41 and not by lld/ELF yet.

The goal is to make the emitted DWARF correct after linking.
Many users don't care about the default DWARF version, but a linker
error will be unacceptable. Let's just downgrade the default DWARF
version, before binutils>=2.41 is more widely available.

An alternative compatibility option is to add a toggle to DwarfDebug.cpp,
but that doesn't seem like a good idea.

Reviewed By: asb, kito-cheng

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

(cherry picked from commit bbc0f99f3bc96f1db16f649fc21dd18e5b0918f6)
(with a release note)

[clang-tidy] Fix crash when diagnostic is emit with invalid location

Fix crash when diagnostic is emit with invalid location,
but with attached valid ranges. Diagnostic can contain
invalid location, but SourceManager attached to it still
can be valid, use it in such case or fallback to known
SourceManager.

Fixes: #64602

Reviewed By: aaron.ballman

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

(cherry picked from commit efd44f80a5a8194b9fe26ff3244ce702cd8dab73)

Revert "[Sema] Fix handling of functions that hide classes"

This reverts commit d031ff38779bd688c514136dbdcce3169ee82b6e.
See https://reviews.llvm.org/D154503#4576393 for a reproducer and
details.

(cherry picked from commit 7d259b36d2e8148d13087844e6494ad3a5c63edf)

[flang] Add missing dependency on tablegen files

This issue was raised on https://github.com/llvm/llvm-project/issues/64268.

`flang/lib/Optimizer/Transforms/SimplifyIntrinsics.cpp` includes
`flang/Optimizer/HLFIR/HLFIRDialect.h` and might fails if the HLFIR related
tablegen files have not been generated.

Reviewed By: vzakhari

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

(cherry picked from commit 103907bc5fcf656b1551e191af8176cd7bfb91da)

[SDAG] Don't transfer !range metadata without !noundef to SDAG (PR64589)

D141386 changed the semantics of !range metadata to return poison
on violation. If !range is combined with !noundef, violation is
immediate UB instead, matching the old semantics.

In theory, these IR semantics should also carry over into SDAG.
In practice, DAGCombine has at least one key transform that is
invalid in the presence of poison, namely the conversion of logical
and/or to bitwise and/or (https://github.com/llvm/llvm-project/blob/c7b537bf0923df05254f9fa4722b298eb8f4790d/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#L11252).
Ideally, we would fix this transform, but this will require
substantial work to avoid codegen regressions.

In the meantime, avoid transferring !range metadata without
!noundef, effectively restoring the old !range metadata semantics
on the SDAG layer.

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

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

(cherry picked from commit 9deee6bffa9c331f46c68e5dd4cb4abf93dc0716)

[X86] Add test for PR64589 (NFC)

(cherry picked from commit 59d558a37850611f9b63a5c1a8bfe87a9606c81e)

[SelectionDAG] Fix problematic call to EVT::changeVectorElementType().

The function changeVectorElementType assumes MVT input types will
result in MVT output types.  There's no gurantee this is possible
during early code generation and so this patch converts an instance
used during initial DAG construction to instead explicitly create a
new EVT.

NOTE: I could have added more MVTs, but that seemed unscalable as
you can either have MVTs with 100% element count coverage or 100%
bitwidth coverage, but not both.

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

(cherry picked from commit b7e6e568b4f28124060b868e433f36af18c510db)

Revert "[AggressiveInstCombine] Fold strcmp for short string literals"

This reverts commit 8981520b19f2d2fe3d2bc80cf26318ee6b5b7473.

[CMake] Set version suffix to `rc` during the RC phase

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

[clang-tidy] fix None tmpdir when exporting fixes in run-clang-tidy

Differential https://reviews.llvm.org/D145477 removed the check for `(yaml and args.export_fixes)` in line 303 to skip looking for the `clang-apply-replacements` binary. However, the `tmpdir` variable was set in this true branch when exporting fixes and therefore is `None` when invoking run-clang-tidy with `run-clang-tidy -p . -export-fixes fixes.yaml`.

Reviewed By: PiotrZSL

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

(cherry picked from commit c3da99275a520b73235d975017502876e07e3e8e)

[BPF] Don't crash on missing line info

When compiling Rust code we may end up with calls to functions provided
by other code units. Presently this code crashes on a null pointer
dereference - this patch avoids that crash and adds a test.

Reviewed By: ast

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

(cherry picked from commit 055893beacb34441467eb997a270a620c57c138f)

[AMDGPU] Do not release VGPRs at -O0

This was an oversight when the GFX11 early release VGPRs optimization
was reimplemented in D153279.

Sending the DEALLOC_VGPRS message is a performance optimization so there
is no need to do it at -O0. In addition it makes some kinds of post
mortem debugging hard or impossible, since VGPR values are no longer
available to inspect at the s_endpgm instruction.

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

(cherry picked from commit 3091bdb86d55e404866823b64d21fd87c247d893)

[RISCV] Fix wrong type prototype of RVVSlideOneBuiltinSet

We need unsigned integer here.

Fixes #64534

Reviewed By: eopXD

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

(cherry picked from commit 5a3753f35632f8fd7920c5c99b1237113b5c435e)

[Driver] Allow for sparcv8plus subdir with Solaris/SPARC GCC

Since GCC 11, the bundled Solaris/SPARC GCC uses the `sparcv8plus`
subdirectory for 32-bit objects, just like upstream GCC.  Before that, it
used `32` instead from a local patch.

Since `clang` doesn't know about that `sparcv8plus` subdirectory, it
wouldn't properly use GCC 11+ installations.

The new `solaris-sparc-gcc-search.test` testcase wasn't run initially (like
the existing `crash-report-null.test`) because the `.test` suffix wasn't
handled.

Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.

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

(cherry picked from commit 43dfe0f08ecaf50f986512d0548bd3ac84d1813b)

[Clang] Backport static_assert messages fixes

* 4d494e7: Handle static_assert messages with an expression started by a literal
* 49e0495 Produce a warning instead of an error in unevaluated strings before C++26

Emiting an error on unexpected encoding prefix - which was allowed before C++26 -
caused build errors for a few users.
This downgrade the error to a warning on older language modes and C

[lld][LoongArch] Support the R_LARCH_PCREL20_S2 relocation type

`R_LARCH_PCREL20_S2` is a new added relocation type in LoongArch ELF
psABI v2.10 [1] which is not corvered by D138135 except `R_LARCH_64_PCREL`.

A motivation to support `R_LARCH_PCREL20_S2` in lld is to build the
runtime of .NET core (a.k.a `CoreCLR`) in which strict PC-relative
semantics need to be guaranteed [2]. The normal `pcalau12i + addi.d`
approach doesn't work because the code will be copied to other places
with different "page" and offsets. To achieve this, we can use `pcaddi`
with explicit `R_LARCH_PCREL20_S2` reloc to address +-2MB PC-relative
range with 4-bytes aligned.

[1]: https://github.com/loongson/la-abi-specs/releases/tag/v2.10
[2]: https://github.com/dotnet/runtime/blob/release/7.0/src/coreclr/vm/loongarch64/asmhelpers.S#L307

Reviewed By: xen0n, MaskRay

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

(cherry picked from commit 8a31f7ddb8436fa2a8ad754eb51618139cf63415)

[AArch64][PtrAuth] Fix unwind state for tail calls

When generating unwind tables for code which uses return-address
signing, we need to toggle the RA_SIGN_STATE DWARF register around any
tail-calls, because these require the return address to be authenticated
before the call, and could throw an exception. This is done using the
.cfi_negate_ra_state directive before the call, and .cfi_restore_state
at the start of the next basic block.

However, since D153098, the .cfi_restore_state isn't being inserted,
because the CFIFixup pass isn't being run. This re-enables that pass
when return-adress signing is enabled.

Reviewed By: ikudrin, MaskRay

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

(cherry picked from commit f2e7285b03fbfc263c8a2eaa2b5e2e1cfafc6abd)

[AArch64] Refactor checks in sign-return-address.ll test

Using implicit CHECK prefix in one FileCheck invocation and explicit
CHECK-V83A in the other one seems to misguide to use CHECK: lines as
a common matching prefix at various places. Also note that

; CHECK, CHECK-V83A: ...

line only matches the "CHECK-V83A" prefix.

This commit explicitly splits the checks into common ones (CHECK) and
invocation-specific ones (COMPAT and V83A) and updates the assertions
with the update_llc_test_checks.py script.

Reviewed By: efriedma, MaskRay

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

(cherry picked from commit 4210204f521be3caa0e60bd596af3444cbd44d04)

[PPC][AIX] Fix toc-data peephole bug and some related cleanup.

Set the ReplaceFlags variable to false, since there is code meant only
for the ADDItocHi/ADDItocL nodes. This has the side effect of disabling
the peephole when the load/store instruction has a non-zero offset.
This patch also fixes retrieving the `ImmOpnd` node from the AIX small
code model pseduos and does the same for the register operand node.
This allows cleaning up the later calls to replaceOperands.
Finally move calculating the MaxOffset into the code guarded by
ReplaceFlags as it is only used there and the comment is specific to the ELF
ABI.

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

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

(cherry picked from commit b37c7ed0c95c7f24758b1532f04275b4bb65d3c1)

[RISCV] Add back handling of X > -1 to ISD::SETCC lowering.

There are cases where the -1 doesn't become visible until lowering
so the folding doesn't have a chance to run.

I think in these cases there is a missed DAGCombine for truncate (undef),
which I may fix separately, but RISC-V backend should protect itself.

Fixes #64503.

Reviewed By: asb

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

(cherry picked from commit 7cc615413fd7c93421052a193bc3e114465747c9)

BOLT Release Notes

[llvm-rc] Resolve the executable path if not present in Argv[0]

The llvm-rc tool tries to locate a suitable Clang executable to
use for preprocessing. For this purpose, it first checks within
the same directory as the llvm-rc tool, checking with a couple
different names, followed by checking all of $PATH for another
couple names.

On Windows, the InitLLVM() function always sets up Argv[0] with the
full path to the executable, while on Unix, Argv[0] is kept as is.

Therefore, call getMainExecutable to try to resolve the directory of
the executable before looking for colocated Clang executables.

This makes 282744a9ce18120dc0a6eceb02693b36980d9498 actually have
the desired effect.

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

(cherry picked from commit 8c6a0c8bf50bca6c3a0c4de1b84f21466ee31655)

[libc++][doc] Updates format related release notes.

As suggested by @ldionne.

Reviewed By: ldionne, #libc, avogelsgesang

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

(cherry picked from commit cf83cfb3a569632c0049f11d0f56b851aaf21393)

[MLIR] Make the `ConversionTarget` const ref in the DialectConversion (NFC)

It isn't mutated during the conversion already, communicate this through the API.

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

Clarify the invariant of the MLIR pass pipeline around `Pass::initialize()`

This method should not load new dialect or affect the context itself.

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

[mlir][VectorOps] Fix folding of vector.extract from stretch vector.broadcast

Previously, foldExtractFromBroadcast() would incorrectly fold:

  func.func @extract_from_stretch_broadcast(%src: vector<3x1x2xf32>) -> f32 {
    %0 = vector.broadcast %src : vector<3x1x2xf32> to vector<3x4x2xf32>
    %1 = vector.extract %0[0, 2, 0] : vector<3x4x2xf32>
    return %1: f32
  }

to:

  func.func @extract_from_stretch_broadcast(%src: vector<3x1x2xf32>) -> f32 {
    %0 = vector.extract %src[0, 2, 0] : vector<3x1x2xf32>
    return %0: f32
  }

This was due to the wrong offset being used when zeroing the "dim-1"
broadcasted dims. It should use the difference in rank across the
broadcast as the starting offset, as the ranks after that are the ones
that could have been stretched.

Reviewed By: awarzynski, dcaballe

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

[mlir] Store segment sizes in std::array

This revision uses std::array instead of normal c arrays to store the
operand and result segment sizes. This is a follow up to
https://reviews.llvm.org/D155919, which converted the operand and result
segment sizes to properties. Its use of c arrays triggered warnings in
downstream projects due to the direct comparison of c arrays. This
revision fixes the warnings using std::arrays that implement a
proper comparison operator, which compares the array elements rather
that the array pointers.

Note: it seems the comparison operator is effectively dead code for now.
It still seems useful to fix the warning and ensure the comparison works
as expected assume someone starts using it at some point in time.

Reviewed By: mehdi_amini

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

[MLIR][Bytecode] Add missing field initializer in constructor initializer list

Leaving this field unitialized could led to crashes when it'll diverge from the
IRNumbering phase.

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

[mlir] Reduce warnings for bad assertion in generated code

When the operation has no attributes, the generated assertion is
always false and triggers lots of warnings in the build.

```
warning: comparison of unsigned expression < 0 is always false
```

Just return a StringAttr when there is no attribute.

Reviewed By: mehdi_amini

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

[mlir][llvm] Fix export of 64-bit integer function attributes

The `allocsize` attribute is weird because it packs two 32-bit values
into a 64-bit value. It also turns out that the passthrough attribute
exporter was using `int`, which is incorrectly handling 64-bit integers.

Reviewed By: rriddle

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

[mlir][gpu] NFC - Fail gracefully when type conversion fails instead of crashing

[mlir] Fix arith verifier for tensor with encoding

The verifier for some arith ops were not considering that ranked
tensor types can have encodings.

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

[mlir][LLVMIR] Fix identified structs with same name

Different identified struct types may have the same name ("").
Previously, these were deduplicated based on their name, which caused
an assertion failure when nesting identified structs:

    %0 = type { %1 }
    %1 = type { i8 }
    declare void @fn(%0)

Reviewed By: gysit

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

[mlir-lsp] Guard writing output to JSONTransport with mutex

This allows for users of the lsp transport libraries to process replies
in parallel, without overlapping/clobbering the output.

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

[mlir:bytecode] Only visit the all regions path if the op has regions

Zero region operations return true for both isBeforeAllRegions and
isAfterAllRegions when using WalkStage. The bytecode walk only
expects region holding operations in the after regions path, so
guard against that.

[mlir:bytecode] Support lazy loading dynamically isolated regions

We currently only support lazy loading for regions that
statically implement the IsolatedFromAbove trait, but that
limits the amount of operations that can be lazily loaded. This review
lifts that restriction by computing which operations have isolated
regions when numbering, allowing any operation to be lazily loaded
as long as it doesn't use values defined above.

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

[mlir:bytecode] Fix bytecode lazy loading for ops with multiple regions

We currently encode each region as a separate section, but
the reader expects all of the regions to be in the same section.
This updates the writer to match the behavior that the reader
expects.

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

Add release notes for MLIR

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

[mlir] Fix assembly format parser generator after 9ea6b30ac20f8223fb6aeae853e5c73691850a8d.

[mlir][spirv] Do not introduce vector<1xT> in UnifyAliasedResource

1-element vectors are not valid in SPIR-V and fail `Bitcast` op verification.

Reviewed By: antiagainst

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

[CodeGen] Disable FP LD1RX instructions generation for Neoverse-V1

These instructions show worse performance on Neoverse-V1 compared
to pair of LDR(LDP)/MOV instructions.
This patch adds `no-sve-fp-ld1r` sub-target feature, which is enabled
only on Neoverse-V1.

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

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

(cherry picked from commit 60e2a849b0a537f96ca12fb032c4a0e32e07b4ae)

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

(cherry picked from commit 27dab4d305acb6e0935e014c061c5317016ae2b3)

[llvm-exegesis] Don't try to use SYS_rseq if it's not defined.

When compiling against recent glibc (>= 2.35) but old kernel headers (< 4.18), `SYS_rseq` is not defined and thus llvm-exegesis fails to build. So also check that `SYS_rseq` is defined before trying to use it.

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

Reviewed By: MaskRay, gchatelet

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

(cherry picked from commit f70e83af7a708a22fdde8c644ac5810223090cd4)

[CodeGen] Fix incorrect pattern FMLA_* pseudo instructions

* Remove the incorrect patterns from AArch64fmla_p/AArch64fmls_p
* Add correct patterns to AArch64fmla_m1/AArch64fmls_m1
* Refactor fma_patfrags for the sake of PatFrags

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

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

(cherry picked from commit 84d444f90900d1b9d6c08be61f8d62090df28042)

[CodeGen] Precommit tests for D157095

(cherry picked from commit 7542477d5d6e10848ac9ba5dd5421afc7e4947d2)

[CodeGen] Pre-commit tests showing incorrect pattern FMLA_* pseudo instructions

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

(cherry picked from commit b560d5c7e380c1c412b892a3e22f8ee15a522381)

[lldb][AArch64] Save/restore TLS registers around expressions

This was cherry-picked from 6239227172cdc92f3bb72131333f50f83a6439cf and has been
modified to remove references to the tpidr2 register that is not supported on
the 17 branch.

Previously lldb was storing them but not restoring them. Meaning that this function:
```
void expr(uint64_t value) {
  __asm__ volatile("msr tpidr_el0, %0" ::"r"(value));
}
```
When run from lldb:
```
(lldb) expression expr()
```
Would leave tpidr as `value` instead of the original value of the register.

A check for this scenario has been added to TestAArch64LinuxTLSRegister.py,

Reviewed By: omjavaid

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

[lldb][AArch64] Add reading of TLS tpidr register from core files

7e229217f4215b519b886e7881bae4da3742a7d2 did live processes, this does
core files. Pretty simple, there is an NT_ARM_TLS note that contains
at least tpidr, and on systems with the Scalable Matrix Extension (SME), tpidr2
as well.

tpidr2 will be handled in future patches for SME support.

This NT_ARM_TLS note has always been present but it seems convenient to
handle it as "optional" inside of LLDB. We'll probably want the flexibility
when supporting tpidr2.

Normally the C library would set tpidr but all our test sources build
without it. So I've updated the neon test program to write to tpidr
and regenerated the corefile.

I've removed the LLDB_PTRACE_NT_ARM_TLS that was unused, we get
what we need from llvm's defs instead.

Reviewed By: omjavaid

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

Revert "[Clang] Fix -Wconstant-logical-operand when LHS is a constant"

This reverts commit dfdfd306cfaf54fbc43e2d5eb36489dac3eb9976.

An issue is reported for wrong warning, this has to be reconsidered.

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

[libc++][libunwind] Fixes to allow GCC 13 to compile libunwind/libc++abi/libc++

These are changes to allow GCC 13 to successfully compile the runtimes stack.

Reviewed By: ldionne, #libc, #libunwind, MaskRay

Spies: MaskRay, zibi, SeanP, power-llvm-team, mstorsjo, arichardson, libcxx-commits

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

(cherry picked from commit 3537338d1ab9b6da4b58499877953deb81c59e5e)

[TailCallElim] Remove the readonly attribute of byval.

When eliminating a tail call, we modify the values of the arguments.
Therefore, if the byval parameter has a readonly attribute, we have to remove it. It is safe because,
from the perspective of a caller, the byval parameter is always treated as "readonly," even if the readonly attribute is removed.

Fixes #64289.

Reviewed By: nikic

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

(cherry picked from commit c3f227ead65c606409ff8cc3333a6c751f156a9c)

[TailCallElim] Regenerate test checks with --function-signature (NFC)

For checking the readonly attribute.

Pre-commit test for D156793.

Reviewed By: nikic

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

(cherry picked from commit b77e5563f6bc4b5a81d427bf0f42ebea8ca376f0)

[LoongArch] Support -march=native and -mtune=

As described in [1][2], `-mtune=` is used to select the type of target
microarchitecture, defaults to the value of `-march`. The set of
possible values should be a superset of `-march` values. Currently
possible values of `-march=` and `-mtune=` are `native`, `loongarch64`
and `la464`.

D136146 has supported `-march={loongarch64,la464}` and this patch adds
support for `-march=native` and `-mtune=`.

A new ProcessorModel called `loongarch64` is defined in LoongArch.td
to support `-mtune=loongarch64`.

`llvm::sys::getHostCPUName()` returns `generic` on unknown or future
LoongArch CPUs, e.g. the not yet added `la664`, leading to
`llvm::LoongArch::isValidArchName()` failing to parse the arch name.
In this case, use `loongarch64` as the default arch name for 64-bit
CPUs.

Two preprocessor macros are defined based on user-provided `-march=`
and `-mtune=` options and the defaults.
- __loongarch_arch
- __loongarch_tune
Note that, to work with `-fno-integrated-cc1` we leverage cc1 options
`-target-cpu` and `-tune-cpu` to pass driver options `-march=` and
`-mtune=` respectively because cc1 needs these information to define
macros in `LoongArchTargetInfo::getTargetDefines`.

[1]: https://github.com/loongson/LoongArch-Documentation/blob/2023.04.20/docs/LoongArch-toolchain-conventions-EN.adoc
[2]: https://github.com/loongson/la-softdev-convention/blob/v0.1/la-softdev-convention.adoc

Reviewed By: xen0n, wangleiat, steven_wu, MaskRay

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

(cherry picked from commit f62c9252fc0f1fa0a0f02033659db052c2202a4c)

Revert "Reland "[LoongArch] Support -march=native and -mtune=""

This reverts commit c56514f21b2cf08eaa7ac3a57ba4ce403a9c8956. This
commit adds global state that is shared between clang driver and clang
cc1, which is not correct when clang is used with `-fno-integrated-cc1`
option (no integrated cc1). The -march and -mtune option needs to be
properly passed through cc1 command-line and stored in TargetInfo.

(cherry picked from commit 42c9354a928d4d9459504527085fccc91b46aed3)

[libc++] Deflake the Clang Modules CI job

This re-introduces the workaround that had been introduced in d7ca140c0122
and then removed in 0c0628c92c0d, since it seems like it is needed after all.

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

(cherry picked from commit d2a61db072e90ca15a8e5bc053aab878af5cb92a)

workflows/release-tasks: Add missing sudo

(cherry picked from commit ffecb43c4812707be07a9810f21b7b407480f868)

[clang][hexagon] Handle library path arguments earlier

The removal of the early return in 96832a6bf7e0e7f1e8d634d38c44a1b32d512923
was an error: it would include the 'standalone' library that's not used
by linux.

Instead we reproduce the library path handling in the linux/musl block.

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

(cherry picked from commit 5bc4b34a3aa9c6ea10663a252ac46d20862b38d5)

[PPC32] Parse bl __tls_get_addr(x@tlsgd)@plt+32768

PPC32 -fpic/-fPIC generates `bl __tls_get_addr(x@tlsgd)@PLT` or
`bl __tls_get_addr(x@tlsgd)@PLT+32768`.
`powerpc-linux-gnu-gcc -fPIC` generates `bl __tls_get_addr+32668(x@tlsgd)@plt`.

These expressions can be parsed by GNU assembler but not by the integrated
assembler. Add the support.

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

(cherry picked from commit 6e07e90890d61b1be19d3f5fbf00ea7430068325)

[CodeGen] Improve speed of ComplexDeinterleaving pass

Cache all results of running `identifyNode`, even those that do not identify
potential complex operations. This patch prevents ComplexDeinterleaving pass
from repeatedly trying to identify Nodes for the same pair of instructions.

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

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

(cherry picked from commit 46b2ad0224d3c9a9cc299211213e2cf677f5a78c)

Bump version to 17.0.0-rc2

[libc++][modules] Fixes exporting named declarations.

@ChuanqiXu noticed std::atomic was not properly exported in the std module.
Investigation showed other named declarations were not exported either. This
fixes the issue.

Depends on D156550

Reviewed By: #libc, philnik

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

(cherry picked from commit e57f6f709ed2ebef7852bebb47baaf202962b4ee)

[clang/cxx-interop] Teach clang to ignore availability errors that come from CF_OPTIONS

This cherry-picks https://github.com/apple/llvm-project/pull/6431
since without it, macOS 14 SDK headers don't compile when targeting
catalyst.

Fixes #64438.

(cherry picked from commit bb58748e52ebd48a46de20525ef2c594db044a11)

[Clang][LoongArch] Fix ABI handling of empty structs in C++ to match GCC behaviour

GCC doesn't ignore non-zero-length array of empty structures in C++
while clang does. What this patch did is to match GCC's behaviour
although this rule is not documented in psABI.

Similar to D142327 for RISCV.

Reviewed By: xry111, xen0n

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

Revert "[clang][X86] Add __cpuidex function to cpuid.h"

This reverts commit 2df77ac20a1ed996706b164b0c4ed5ad140f635f.

This has been causing some issues with some windows builds as
_MSC_EXTENSIONS isn't defined when only -fms-extensions is set, but the
builtin that conflicts with __cpuidex is. This was also causing problems
as it exposed some latent issues with how auxiliary triples are handled
in clang.

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

(cherry picked from commit f3baf63d9a1ba91974f4df6abb8f2abd9a0df5b5)

AMDGPU: Remove note about spill handling changes

This was reverted from the release by
8ff26437cfd37a3611d3b6066e5aa2cf933887e0

MIPS: clear_cache, use _flush_cache instead of cacheflush

The cacheflush is only defined with __USE_MISC, which depends on _DEFAULT_SOURCE,
_GNU_SOURCE or _BSD_SOURCE, or _SVID_SOURCE.

If CC is called with -std=c11, these macros won't be defined, Let's use
_flush_cache, which is defined always.

Reviewed By: brad, jrtc27

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

(cherry picked from commit 0f99bc2d685c572c3b38fd0e1ca56be12d7e2f6a)

[libc++][print] Mark some more `<print>` tests as requiring a file system.

A follow-up to https://reviews.llvm.org/D156585.

(cherry picked from commit e6b2e1b88248c1f5b34fde4e51aaeb99f849b580)

[clang][RISCV] Fix bug in ABI handling of empty structs with hard FP calling conventions in C++

As reported in <https://github.com/llvm/llvm-project/issues/58929>,
Clang's handling of empty structs in the case of small structs that may
be eligible to be passed using the hard FP calling convention doesn't
match g++. In general, C++ record fields are never empty unless
[[no_unique_address]] is used, but the RISC-V FP ABI overrides this.

After this patch, fields of structs that contain empty records will be
ignored, even in C++, when considering eligibility for the FP calling
convention ('flattening'). It isn't explicitly noted in the RISC-V
psABI, but arrays of empty records will disqualify a struct for
consideration of using the FP calling convention in g++. This patch
matches that behaviour. The psABI issue
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/358> seeks
to clarify this.

This patch was previously committed but reverted after a bug was found.
This recommit adds additional logic to prevent that bug (adding an extra
check for when a candidate from detectFPCCEligibleStructHelper may not
be valid).

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

Revert "Reapply: [MemCpyOpt] implement single BB stack-move optimization which unify the static unescaped allocas"""

Breaks Asan and LTO.

This reverts commit ea72b5137eb72391ad192dbb01084c21b9fe8b71.

(cherry picked from commit 00653889883f2d818536efcb21c6c8b739f0888b)

Revert "[CodeGen]Allow targets to use target specific COPY instructions for live range splitting"

And dependent commits.

Details in D150388.

This reverts commit 825b7f0ca5f2211ec3c93139f98d1e24048c225c.
This reverts commit 7a98f084c4d121244ef7286bc6503b6a181d446e.
This reverts commit b4a62b1fa546312d882fa12dfdcd015177d66826.
This reverts commit b7836d856206ec39509d42529f958c920368166b.

No conflicts in the code, few tests had conflicts in autogenerated CHECKs:
llvm/test/CodeGen/Thumb2/mve-float32regloops.ll
llvm/test/CodeGen/AMDGPU/fix-frame-reg-in-custom-csr-spills.ll

Reviewed By: alexfh

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

(cherry picked from commit a496c8be6e638ae58bb45f13113dbe3a4b7b23fd)

[sanitizer_common] Remove hacks for __builtin_return_address abuse on SPARC

As detailed in Issue #57624, the introduction of
`__builtin_extract_return_address` to `GET_CALLER_PC` in
4248f32b9ebe87c7af8ee53911efd47c2652f488
<https://reviews.llvm.org/rG4248f32b9ebe87c7af8ee53911efd47c2652f488> broke
`TestCases/Misc/missing_return.cpp` on Solaris/SPARC.  Unlike most other
targets, the builtin isn't a no-op on SPARC and thus has always been
necessary. Its lack had previously been worked around by calls to
`GetNextInstructionPc` in `sanitizer_stacktrace_sparc.cpp`
(`BufferedStackTrace::UnwindFast`) and `sanitizer_unwind_linux_libcdep.cpp`
(`BufferedStackTrace::UnwindSlow`).  However, those calls are superfluous
now and actually harmful.

This patch removes those hacks, fixing the failure.

Tested on `sparcv9-sun-solaris2.11` and on `sparc-sun-solaris2.11` in the
GCC tree.  On the latter, several more testcase failures had been caused by
this issue since ASan actually works with `gcc` on SPARC, unlike `clang`.

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

(cherry picked from commit 679c076ae446af81eba81ce9b94203a273d4b88a)

cmake: add missing dependencies on ClangDriverOptions tablegen

This is a follow-up to 2fb1c1082c01

(cherry picked from commit 3d756c32cdf005d0f4c05f561fec4a37b64b7ddd)

[SymbolSize] Improve the performance of SymbolSize computation

The current algorithm to compute the symbol size is quadratic if there
are lots of symbols sharing the same addresses. This happens in a debug
build when lots of debug symbols get emitted in the symtab.

This patch improves the performance like `llvm-symbolizer` that relies
on the symbol size computation. Symbolizing a release+assert clang with
DebugInfo sees significant improvements from 3:40min to less than 1s.

Reviewed By: pete, mehdi_amini, arsenm, MaskRay

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

(cherry picked from commit f5974e80653db977913bceffca7e900e818ef872)

Retain all jump table range checks when using BTI.

This modifies the switch-statement generation in SelectionDAGBuilder,
specifically the part that generates case clusters of type CC_JumpTable.

A table-based branch of any kind is at risk of being a JOP gadget, if
it doesn't range-check the offset into the table. For some types of
table branch, such as Arm TBB/TBH, the impact of this is limited
because the value loaded from the table is a relative offset of
limited size; for others, such as a MOV PC,Rn computed branch into a
table of further branch instructions, the gadget is fully general.

When compiling for branch-target enforcement via Arm's BTI system,
many of these table branch idioms use branch instructions of types
that do not require a BTI instruction at the branch destination. This
avoids the need to put a BTI at the start of each case handler,
reducing the number of available gadgets //with// BTIs (i.e. ones
which could be used by a JOP attack in spite of the BTI system). But
without a range check, the use of a non-BTI-requiring branch also
opens up a larger range of followup gadgets for an attacker's use.

A defence against this is to avoid optimising away the range check on
the table offset, even if the compiler believes that no out-of-range
value should be able to reach the table branch. (Rationale: that may
be true for values generated legitimately by the program, but not
those generated maliciously by attackers who have already corrupted
the control flow.)

The effect of keeping the range check and branching to an unreachable
block is that no actual code is generated at that block, so it will
typically point at the end of the function. That may still cause some
kind of unpredictable code execution (such as executing data as code,
or falling through to the next function in the code section), but even
if so, there will only be //one// possible invalid branch target,
rather than giving an attacker the choice of many possibilities.

This defence is enabled only when branch target enforcement is in use.
Without branch target enforcement, the range check is easily bypassed
anyway, by branching in to a location just after it. But with
enforcement, the attacker will have to enter the jump table dispatcher
at the initial BTI and then go through the range check. (Or, if they
don't, it's because they //already// have a general BTI-bypassing
gadget.)

Reviewed By: MaskRay, chill

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

(cherry picked from commit 60b98363c7ed0a549be4d51ee07c32dc2bf47d2f)

[libc++][print] Make `<print>` tests require file system support.

`print` functions require `FILE` and `stdout` to be available and cause
compilation errors on platforms that don't support the file system.

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

(cherry picked from commit 1cf970db4e5499f6b38d9c6644935a78d758802c)

[libc++][mdspan] Fix layout_left::stride(r)

It was using the stride calculation of layout_right.

Reviewed By: philnik

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

(cherry picked from commit 0f4d7d81c9d08512a3871596fa2a14b737233c80)

[RISCV] Use max pushed register to get pushed register number.

Previously we used the number of registers needed saved and pushable as the
number of pushed registers. We also use pushed register number to caculate
the stack size. It is not correct because Zcmp pushes registers from $ra to the
max register needed saved and there is no gurantee that the needed saved
registers are a sequenced list from $ra.

There is an example about that. PushPopRegs should be 6 (ra,s0 - s4)= instead of 1.
```
; llc -mtriple=riscv32 -mattr=+zcmp
define void @foo() {
entry:
; Old:    .cfi_def_cfa_offset 16
; New:    .cfi_def_cfa_offset 32
  tail call void asm sideeffect "li s4, 0", "~{s4}"()
  ret void
}
```

Reviewed By: Jim, kito-cheng

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

(cherry picked from commit f68c6879ad0e08e6509b89f60ed436d3be409f9c)

Commit to a primary definition for a class when we load its first
member.

Previously, we wouldn't do this if the first member loaded is within a
definition that's added to a class via an update record, which happens
when template instantiation adds a class definition to a declaration
that was imported from an AST file.

This would lead to classes having member functions whose getParent
returned a class declaration that wasn't the primary definition, which
in turn caused the vtable builder to build broken vtables.

I don't yet have a reduced testcase for the wrong-code bug here, because
the setup required to get us into the broken state is very subtle, but
have confirmed that this fixes it.

(cherry picked from commit 61c7a9140becb19c5b1bc644e54452c6f782f5d5)

Remove stale info and fix superscript numbering

This amends 1e06b82bded69fe627d6cd62ecff236fca15f39b

(cherry picked from commit 80e80fa79bf66a74caf959bc420823e2b544dee9)

[docs] Bump minimum GCC version to 7.4

GCC 7.3 cannot build 16.x releases.
```
In file included from /tmp/llvm-16/llvm/lib/Transforms/IPO/AttributorAttributes.cpp:14:0:
/tmp/llvm-16/llvm/include/llvm/Transforms/IPO/Attributor.h:1137:32: error: duplicate initialization of ‘llvm::AnalysisGetter::HasLegacyWrapper<Analysis, std::void_t<typename Analysis::Lega
cyWrapper> >’
 constexpr bool AnalysisGetter::HasLegacyWrapper<
                                ^~~~~~~~~~~~~~~~~
       Analysis, std::void_t<typename Analysis::LegacyWrapper>> = true;
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/llvm-16/llvm/include/llvm/Transforms/IPO/Attributor.h:1137:32: error: got 1 template parameters for ‘constexpr const bool llvm::AnalysisGetter::HasLegacyWrapper< <template-parameter-1
-1>, <template-parameter-1-2> >’
/tmp/llvm-16/llvm/include/llvm/Transforms/IPO/Attributor.h:1137:32: error:   but 2 required
```

The 17.x and main branches have more failures, e.g.

```
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp: `error: cannot decompose class type ‘std::pair<llvm::Value*, const llvm::SCEV*>’: ...`
```

We probably should just give up 7.1 and say that GCC<=7.3 is unsupported.
There is evidence that GCC 7.4 works.
I have verified that GCC 7.5 is able to build `check-{llvm,clang,clang-tools,lldb,lld,polly,mlir,bolt}`,
but not flang due to at least `flang/Common/enum-class.h` and a `<charconv`> in a unittest.

Link: https://discourse.llvm.org/t/require-gcc-7-5-as-gcc-7-3-cannot-build-llvm/72310
Reviewed By: aaron.ballman

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

(cherry picked from commit 1e06b82bded69fe627d6cd62ecff236fca15f39b)

[TableGen] Improve error report of unspecified arguments

Wrong error message is fixed and a note of argument is printed.

Tests are added in `llvm/test/TableGen/template-args.td`.

Reviewed By: DavidSpickett

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

(cherry picked from commit eb6987027e0504adcdc319f080a9ea48aab2a72a)

[X86] Workaround possible CPUID bug in Sandy Bridge.

Don't access leaf 7 subleaf 1 unless subleaf 0 says it is
supported via EAX.

Intel documentation says invalid subleaves return 0. We had been
relying on that behavior instead of checking the max sublef number.

It appears that some Sandy Bridge CPUs return at least the subleaf 0
EDX value for subleaf 1. Best guess is that this is a bug in a
microcode patch since all of the bits we're seeing set in EDX were
introduced after Sandy Bridge was originally released.

This is causing avxvnniint16 to be incorrectly enabled with -march=native
on these CPUs.

Reviewed By: pengfei, anna

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

(cherry picked from commit 2a5e3f4c6c2cdd2aab55fbfdb703ca8163351ea9)

Multilib & mfloat-abi release notes

[PowerPC][MC] Recognize tlbilx and its mnemonics

This fixes issue 64080. tlbilx exists in ISA 2.07 Book III-E. Since
contents of Book III-E were eliminated after ISA 3.0, tlbilx does not
exist in ISA 3.0 and ISA 3.1.

Reviewed By: nickdesaulniers

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

(cherry picked from commit 53648ac1d0c953ae6d008864dd2eddb437a92468)

[libc++] Fix `std::out_of_range` thrown from `basic_stringbuf::str() &&`

Reviewed By: #libc, Mordante, philnik

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

(cherry picked from commit f418cb1a9367d85c7c9b1aa93dc3fa60c8ef9849)

[RISCV] Fix the CFI offset for callee-saved registers stored by Zcmp push.

Issue mentioned: https://github.com/riscv/riscv-code-size-reduction/issues/182

The order of callee-saved registers stored by Zcmp push in memory is reversed.

Pseudo code for cm.push in https://github.com/riscv/riscv-code-size-reduction/releases/download/v1.0.4-1/Zc.1.0.4-1.pdf

```
if (XLEN==32) bytes=4; else bytes=8;

addr=sp-bytes;
for(i in 27,26,25,24,23,22,21,20,19,18,9,8,1)  {
  //if register i is in xreg_list
  if (xreg_list[i]) {
    switch(bytes) {
      4:  asm("sw x[i], 0(addr)");
      8:  asm("sd x[i], 0(addr)");
    }
    addr-=bytes;
  }
}
```

The placement order for push is s11, s10, ..., ra.

CFI offset should be calculed as reversed order for correct stack unwinding.

Reviewed By: fakepaper56, kito-cheng

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

Revert "[AArch64] Merge LDRSWpre-LD[U]RSW pair into LDPSWpre"

This reverts commit b0093e13fcfdd4eea5bbd7ae57d3d1b82f4135c3 due to a miscompile
under MSan. See https://reviews.llvm.org/D152407#4533478 for more details.

Reviewed By: asmok-g

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

(cherry picked from commit 0def4e6b0f638b97a73bd4674365961d8fabda28)