[Frontend] Restore Preprocessor::getPredefines()

https://reviews.llvm.org/rG6bbf51f3ed59ae37f0fec729f25af002111c9e74 from May removed Preprocessor::getPredefines() from Clang's API, presumably as a cleanup because this method is unused in the LLVM codebase.

However, it was/is used by a small number of third-party tools and is pretty harmless, so this patch adds it back and documents why it's here.

The issue was raised in https://github.com/llvm/llvm-project/issues/57483, it would be nice to be able to land it into Clang 15 as it breaks those third-party tools and we can't easily add it back in bug fix releases.

Reviewed By: brad.king, thieta

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

(cherry picked from commit bb9dedce5d01f5608acd784942481f386c710c0d)

[docs] Add "Standard C++ Modules"

We get some standard C++ module things done in clang15.x. But we lack a
user documentation for it. The implementation of standard C++ modules
share a big part of codes with clang modules. But they have very
different semantics and user interfaces, so I think it is necessary to
add a document for Standard C++ modules. Previously, there were also
some people ask the document for standard C++ Modules and I couldn't
offer that time.

Reviewed By: iains, Mordante, h-vetinari, ruoso, dblaikie, JohelEGP,
aaronmondal

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

(cherry picked from commit b1d5af81249dc7e5697faf9ee33f86012ccd8668)

[SLP]Fix PR57447: Assertion `!getTreeEntry(V) && "Scalar already in tree!"' failed.

The pointer operands for the ScatterVectorize node may contain
non-instruction values and they are not checked for "already being
vectorized". Need to check that such pointers are already vectorized and
gather them instead of trying to build vectorize node to avoid compiler
crash.

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

(cherry picked from commit ec06df9459136ed538c07d32db16163999c350fe)

[MCContext] Reverse order of DebugPrefixMap sort for generated assembly debug info

Match Clang's sorting, so that longer (more specific) prefix paths will match
before less specific paths.

Reviewed By: MaskRay, raj.khem, #debug-info

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

(cherry picked from commit 3922ec46b84a877a9ac6ce4cfa765c4c847d097d)

[LAA] Require AddRecs to be in the innermost loop for diff-checks.

The simpler diff-checks require pointers with add-recs from the same
innermost loop, but this property wasn't check completely. Add the
missing check to ensure both addrecs are in the innermost loop.

Fixes #57315.

(cherry picked from commit 9405af1c850139f6ddd6d35ff395756fe2aef31f)

[LV]  Add another test for incorrect runtime check generation.

Add a variation of @nested_loop_outer_iv_addrec_invariant_in_inner with
the dependence sink and source swapped to extend test coverage.

Also simplifies the test by removing an unneeded reduction.

(cherry picked from commit e117137af0a37ac309d40db57ec7162ef3d22c29)

[LV] Add test for incorrect runtime check generation #57315.

Test for PR57315 based on a test provided by @kpdev42.

(cherry picked from commit 6e56779e6bc168a3acd14f9bf2c4fd3fd9d86bd1)

[LV] Convert runtime diff check test to use opaque pointers.

Modernize the test to make it easier to extend with up-to-date IR.

(cherry picked from commit 3b135ef446d56e8542d55a1b716e9413f50da7aa)

Fix formatting in release notes

Code needs double backticks, while single backticks produce italics.
Lists need to be fully indented and have blank lines around them.
Links are written "`text <url>`_".

We use links instead of `:manpage:`, because the latter is meant
more for man pages cross-referencing each other.

Reviewed By: aaron.ballman, thieta

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

[lld] Fix typo in 15.x release notes

The flag is -femit-dwarf-unwind, not -femit-compact-unwind.

[ReleaseNotes]: Add PowerPC release notes for LLVM 15

[workflow] Run release tasks for me (tru) as well.

Reviewed By: tstellar

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

[release] Use threaded compression with xz

Use xz -T0 to use your threads

Reviewed By: tstellar

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

[X86][FP16] Add the missing legal action for EXTRACT_SUBVECTOR

Fixes #57340

Reviewed By: RKSimon

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

(cherry picked from commit 12b203ea7c65071f9fc02d420b28d58dcdc5ad4a)

[LLD] [COFF] Fix export directives in object files from -includeoptional

When an object file contains an export directive, we normally do some
amount of deferred processing of them at the end of the linking
process. The -includeoptional option was handled after this, and
any object files (defining new exports) weren't handled.

Move the handling of the -includeoptional into the same late loop
which does the fixups for e.g. export directives.

Ideally, this would also be done for object files that are pulled
in by the wrap options, and for mingw autoimports, but those changes
require more modifications, to make them safe for potentially
being executed multiple times.

This fixes https://github.com/llvm/llvm-project/issues/57243.

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

(cherry picked from commit af39e6f6fc905f3c067f022fb44136779d2f9c84)

[NFC] Fix a misleading comment CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

SONAME introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

This reverts commit bc39d7bdd4977a953b2e102f8f7eb479ad78984e.

rename CLANG_SONAME to LIBCLANG_SOVERSION

[clang][cmake] introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

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

[DAG] MatchRotate - bail if we fail to match a shl/srl pair

extractShiftForRotate may fail to return canonicalized shifts due to constant folding or other simplification that can occur in getNode()

Fixes Issue #57283

(cherry picked from commit e624f8a3bb88075493dec521408993ea0ef7bde0)

[runtimes] Use a response file for runtimes test suites

We don't know which test suites are going to be included by runtimes
builds so we cannot include those before running the sub-build, but
that's not possible during the LLVM build configuration. We instead use
a response file that's populated by the runtimes build as a level of
indirection.

This addresses the issue described in:
https://discourse.llvm.org/t/cmake-regeneration-is-broken/62788

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

(cherry picked from commit 992e10a3fce41255e4b11782f51d0f4b26dca14d)

[lit] Support reading arguments from a file

This allows reading arguments from file using the response file syntax.
We would like to use this in the LLVM build to pass test suites from
subbuilds.

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

(cherry picked from commit b52820edec6f3d95edef7859a56ef30878b08382)

[runtimes] Handle interface targets in runtimes distribution components

As reported in [1], cxx-headers is not a valid distribution target
because it is an interface target in CMake. This breaks the most
basic MultiDistributionExample of the runtimes build.

This patch handles interface targets by getting rid of the assumption
that all distribution components have a target associated to them. It
is valid for a distribution component to only have a `install-FOO`
target.

In the case where only `cxx-headers` is provided as a distribution
component, `ninja toolchain-distribution` will not build anything
after this patch, since there is effectively nothing to build for
the `cxx-headers` target. However, running `ninja install-toolchain-distribution`
will build everything, as expected.

[1]: https://discord.com/channels/636084430946959380/636732894974312448/1010013287464828968

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

(cherry picked from commit 5905e699342fd476d7eb9e35db5d84248a7e9156)

[libc++] Add a missing assertion in std::span's constructor

Also, add missing tests for assertions in span constructors. Now I
believe that all of std::span's API should be hardened, and all the
assertions should have a corresponding test.

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

(cherry picked from commit 8c6319e30a357fb9b25db09b6f5fc9cf3e7c4aab)

Revert "GCC ABI Compatibility: Preserve alignment of non-pod members in packed structs"

This reverts commit 277123376ce08c98b07c154bf83e4092a5d4d3c6.

See issue: https://github.com/llvm/llvm-project/issues/57346

[GTest] Change detection of libpthread

We currently use CMake's find_library function to detect whether
libpthread exists on the system to determine if pthread should
be added on the link step. However, there are configurations in
which CMake's path checking fails to find the library even though
the toolchain has it.

One such case is with Clang 14.0.0 on PowerPC. Due to a recent
change, the build puts libc++ and related libraries in a
subdirectory that appears to depend on the default target triple.
CMake then uses that subdirectory to determine the architecture
and adds that name to its search paths. However, the triple for
the system GNU toolchain is different so CMake fails to find it.
Namely, Clang 14.0.0's default target triple and the subdirectory
name is powerpc64le-unknown-linux-gnu whereas the system GNU
toolchain has powerpc64le-linux-gnu. Clang's driver has no trouble
finding either the GNU includes/libraries or Clang's own. But
CMake seems to get this wrong.

The net result of this is that we can't do a shared libraries
build of ToT with Clang 14.0.0.

This patch proposes using HAVE_LIBPTHREAD which CMake seems to
determine by compiling a test file with -lpthread (or perhaps
-pthread, I can't really get CMake to tell me how it is figuring
this out). If that variable tells CMake that the build compiler
accepts the pthread option, it seems reasonable to depend on
that variable to determine if we should add it to the link step
when building the llvm_gtest library.

(cherry picked from commit 8537a99b2c1d08e9e586b3fb9e36728075ec4a03)

[CUDA] Fix output name being replaced in device-only mode

When performing device only compilation, there was an issue where
`cubin` outputs were being renamed to `cubin` despite the user's name.
This is required in a normal compilation flow as the Nvidia tools only
understand specific filenames instead of checking magic bytes for some
unknown reason. We do not want to perform this transformation when the
user is performing device only compilation.

Reviewed By: tra

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

(cherry picked from commit 3b52341116b794e53dec2fd07e568884e5a0b8bb)

[clangd] Support for standard type hierarchy

This is mostly a mechanical change to adapt standard type hierarchy
support proposed in LSP 3.17 on top of clangd's existing extension support.

This does mainly two things:
- Incorporate symbolids for all the parents inside resolution parameters, so
  that they can be retrieved from index later on. This is a new code path, as
  extension always resolved them eagerly.
- Propogate parent information when resolving children, so that at least one
  branch of parents is always preserved. This is to address a shortcoming in the
  extension.

This doesn't drop support for the extension, but it's deprecated from now on and
will be deleted in upcoming releases. Currently we use the same struct
internally but don't serialize extra fields.

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

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

(cherry picked from commit 83411bf06f34ae06731008eeabfc53553c1a1f86)

[InstCombine] Refactor foldICmpMulConstant

This is a follow-up to 2ebfda2417
(replace "if" with "else if" since the cases nuw/nsw
were meant to be handled separately).

Test plan:
1/ ninja check-llvm check-clang check-lld
2/ Bootstrapped LLVM/Clang pass tests

(cherry picked from commit d982f1e0c69f3447c4520ae4c010520f62ed1174)

[RISCV] Re-enable JIT support

Commit 8922adf646 recently made JITTargetMachineBuilder honor the
hasJIT property of the target. LLVM supports just-in-time compilation
on RISC-V, so set the flag.

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

(cherry picked from commit 940733d6a0a92245912361bf116514172a15f4f8)

[NFC] Minor documentation fix for the release branch

[clang][docs] Release notes for C/C++ SVE Operators

[Sparc] Don't use SunStyleELFSectionSwitchSyntax

As discussed in D85414 <https://reviews.llvm.org/D85414>, two tests
currently `FAIL` on Sparc since that backend uses the Sun assembler syntax
for the `.section` directive, controlled by
`SunStyleELFSectionSwitchSyntax`.

Instead of adapting the affected tests, this patch changes that default.
The internal assembler still accepts both forms as input, only the output
syntax is affected.

Current support for the Sun syntax is cursory at best: the built-in
assembler cannot even assemble some of the directives emitted by GCC, and
the set supported by the Solaris assembler is even larger: SPARC Assembly
Language Reference Manual, 3.4 Pseudo-Op Attributes
<https://docs.oracle.com/cd/E37838_01/html/E61063/gmabi.html#scrolltoc>.

A few Sparc test cases need to be adjusted. At the same time, the patch
fixes the failures from D85414 <https://reviews.llvm.org/D85414>.

Tested on `sparcv9-sun-solaris2.11`.

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

(cherry picked from commit d9993484ee40abaab6d9e96872d3a29044202aea)

[InstCombine] Correct strtol folding with nonnull endptr

Reflect in the pointer's offset the length of the leading part
of the consumed string preceding the first converted digit.

Reviewed By: efriedma

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

(cherry picked from commit bcef4d238d113c61127575bf5dd0328f97bda9e9)

[mlir][test] Require JIT support in JIT tests

A number of mlir tests `FAIL` on Solaris/sparcv9 with `Target has no JIT
support`.  This patch fixes that by mimicing `clang/test/lit.cfg.py` which
implements a `host-supports-jit` keyword for this.  The gtest-based unit
tests don't support `REQUIRES:`, so lack of support needs to be hardcoded
there.

Tested on `amd64-pc-solaris2.11` (`check-mlir` results unchanged) and
`sparcv9-sun-solaris2.11` (only one unrelated failure left).

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

(cherry picked from commit ca98e0dd6cf59907f07201c4282dcafeeea11a91)

[clang][RISCV] Fix incorrect ABI lowering for inherited structs under hard-float ABIs

The hard float ABIs have a rule that if a flattened struct contains
either a single fp value, or an int+fp, or fp+fp then it may be passed
in a pair of registers (if sufficient GPRs+FPRs are available).
detectFPCCEligibleStruct and the helper it calls,
detectFPCCEligibleStructHelper examine the type of the argument/return
value to determine if it complies with the requirements for this ABI
rule.

As reported in bug #57084, this logic produces incorrect results for C++
structs that inherit from other structs. This is because only the fields
of the struct were examined, but enumerating RD->fields misses any
fields in inherited C++ structs. This patch corrects that issue by
adding appropriate logic to enumerate any included base structs.

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

(cherry picked from commit bc538320809fb52af12ec0366118c82201af4f40)

[clang][RISCV][test] Add test that shows incorrect ABI lowering

As reported in <https://github.com/llvm/llvm-project/issues/57084>,
under hard float ABIs there are issues with lowering structs that
inherit from other structs.

See <https://reviews.llvm.org/D131677> for a fix.

(cherry picked from commit d17de5479c6234f9e37fb4deca9e537bf8d3932e)

[SDAG] avoid generating libcall to function with same name

This is a potentially better alternative to D131452 that also
should avoid the infinite loop bug from:
issue #56403

This is again a minimal fix to reduce merging pain for the
release. But if this makes sense, then we might want to guard
all of the RTLIB generation (and other libcalls?) with a
similar name check.

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

(cherry picked from commit 7f72a0f5bb3743428021df920d9a7c50f74f61ae)

[AArch64] add test for recursive libcall lowering; NFC

Issue #56403

(cherry picked from commit 8eddd1ec6066fe958313a2b1cc4907b5ee7dfbee)

workflows/llvm-project-tests: Workaround an issue with lldb builds on Windows

For some reason cmake started selecting a 32-bit version of python on
Windows instead of the 64-bit version when building windows.  Explicitly
setting the default python to 3.10 fixes this problem.

Reviewed By: thieta

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

(cherry picked from commit 99020b3c73c1e22fa388be8fd0c44391d40b3a38)

workflows/version-check: Fix check for release candidates

Reviewed By: thieta

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

(cherry picked from commit 5b108dfc159a461c10bba1fd1f05308bf57dcd25)

[clangd] Fix an inlay-hint crash on a broken designator.

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

(cherry picked from commit 06b97b4985ad0415f6cde4baad2bc7d73b456244)

[flang] Add Solaris/x86 support to Optimizer/CodeGen/Target.cpp

When testing LLVM 15.0.0 rc1 on Solaris, I found that 50+ flang tests
`FAIL`ed with

  error:
/vol/llvm/src/llvm-project/local/flang/lib/Optimizer/CodeGen/Target.cpp:310:
not yet implemented: target not implemented

This patch fixes that for Solaris/x86, where the fix is trivial (just
handling it like the other x86 OSes).

Tested on `amd64-pc-solaris2.11`; only a single failure remains now.

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

(cherry picked from commit bcb2740f415b0f825402f656dda3271414121a0e)

[MC] Avoid C++17 structured bindings

release/15.x uses C++14 and structured bindings trigger warnings in Clang/GCC
and errors in MSVC.

[llvm] [cmake] Move LLVM_INSTALL_PACKAGE_DIR top-level to fix llvm-config

Move the `LLVM_INSTALL_PACKAGE_DIR` declaration from llvm/cmake/modules
directory to the top-level llvm/CMakeLists.txt, in order to fix
the regression in `llvm-config --cmakedir` output for installed LLVM.
Since the tools directory is processed by CMake prior to
llvm/cmake/modules, the llvm-config executable ended up using
the variable prior to it being defined and incorrectly used an empty
path, resulting in e.g.:

    $ llvm-config --cmakedir
    /usr/lib/llvm/16/

With this patch, the path is defined (and therefore the default value
is being set) prior to adding the tools subdirectory and llvm-config
starts working correctly:

    $ llvm-config --cmakedir
    /usr/lib/llvm/16/lib64/cmake/llvm

This fixes a regression introduced by D130539.  Thanks to Petr Polezhaev
for reporting the problem @ https://bugs.gentoo.org/865165

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

(cherry picked from commit d230055234863aafe63489f9ab95e52d2c1883f2)

[clang][SVE] Undefine preprocessor macro defined in

arm_sve.h defines and uses __ai macro which needs to be undefined (as it is
already in arm_neon.h).

Reviewed By: paulwalker-arm

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

(cherry picked from commit 48e1250a91d244741c8677fed248ace1fcd7c41c)

[DAG] Ensure more Legal BUILD_VECTOR elements types in shuffle->And combine

This is a followup to D131350, which caused another problem for i64
types being split into i32 on i32 targets. This patch tries to make sure
that either Illegal types are OK, or that the element types of a
buildvector are legal and bigger than or equal to the size of the
original elements.

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

(cherry picked from commit dfc95bab078297b1564c1ac757b1ac093d125b2d)

[flang] Install runtime libs with the toolchain

Make sure that FortranDecimal, FortranRuntime and Fortran_main are
installed/packaged even when LLVM_INSTALL_TOOLCHAIN_ONLY is enabled.
They are used by flang to link executables, so they should be provided
even with minimal installs.

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

(cherry picked from commit 467abac2046d037f8d4cf428e76b77e5b06c187f)

[RISCV] isImpliedByDomCondition returns an Optional<bool> not a bool.

We were incorrectly checking that it returned an implicaton result,
not that the implication result itself was true.

[DebugInfo] -fdebug-prefix-map: handle '#line "file"' for asm source

`getContext().setMCLineTableRootFile` (from D62074) sets `RootFile.Name` to
`FirstCppHashFilename`. `RootFile.Name` is not processed by -fdebug-prefix-map
and will go to DW_TAG_compile_unit's DT_AT_name and DW_TAG_label's
DW_AT_decl_file. Remap `RootFile.Name`.

Fix another issue reported by https://github.com/llvm/llvm-project/issues/56609

Reviewed By: #debug-info, dblaikie, raj.khem

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

(cherry picked from commit d797c2ffdb591d10de2964907962aaacb2e360ca)

[DebugInfo] Don't join DW_AT_comp_dir and directories[0] for DWARF v5 line tables

DWARF v5 6.2.4 The Line Number Program Header says:

> The first entry is the current directory of the compilation. Each additional
> path entry is either a full path name or is relative to the current directory of
> the compilation.

When forming a path, relative DW_AT_comp_dir and directories[0] are not supposed
to be joined together. Fix getFileNameByIndex to special case DWARF v5 DirIdx == 0.

Reviewed By: #debug-info, dblaikie

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

(cherry picked from commit 3329cec2f79185bafd678f310fafadba2a8c76d2)

[MCDwarf] Respect -fdebug-prefix-map= for generated assembly debug info (DWARF v5)

For generated assembly debug info, MCDwarfLineTableHeader::CompilationDir is an
unmapped path set in MCContext::setGenDwarfRootFile. Remap it.

A relative destination path of -fdebug-prefix-map= exposes a llvm-dwarfdump bug
which joins relative DW_AT_comp_dir and directories[0].

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

Reviewed By: dblaikie

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

(cherry picked from commit f62e60fb238146113f84e0efb1a2ebc52f05cc0a)

[BOLT] Use Optional::emplace to avoid move assignment. NFC

(cherry picked from commit 53113515cdaa19a86e4b807808b7b99dc1c91685)

[MCDwarf][test] Improve debug-prefix-map.s

(cherry picked from commit d561907f27d721558e4372990ca52a8284b7aafc)

[MCDwarf] Use emplace to avoid move assignment. NFC

(cherry picked from commit b0c4cd35df89479ec152c1f79e18d0264dd276cc)

[DAGCombine] Check zext legality in zext-extract-extend combine

Discussed in D131503.

Fix to D130782.

(cherry picked from commit 898699831b5490d88b993593e5cb415fb2d1983a)

[libcxx] [doc] Remove a leftover tentative release note

This release note was added tentatively in
https://reviews.llvm.org/D120982 / ebde6fc23bc0ee9d022fcd26b52bc82dfb7c8468.
The issue was resolved differently in
https://reviews.llvm.org/D125715 / bedf657d0f4c54ffe9ef4303382657a74296b544,
but that commit forgot to remove the tentative release note.

 __has_trivial_copy should map to __is_trivially_copyable

Found during clang 15 RC1 testing due to the new diagnostic added by @royjacobson since clang 14.  Uncertain if this fix meets the bar to also be applied to the release branch.

If accepted, I'll need someone with commit access to submit on my behalf.

Reviewed By: royjacobson, aaron.ballman, erichkeane

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

(cherry picked from commit 64f0f7e6460019a38fe2f1cbe4b9446a3268af18)

[X86][FP16] Promote FP16->[U]INT to FP16->FP32->[U]INT

This is to avoid f16->i64 being lowered to `__fixhfdi/__fixunshfdi` on 32-bits since neither libgcc nor compiler-rt provide them. https://godbolt.org/z/cjWEsea5v

It also helps to improve the performance by promoting the vector type.

Reviewed By: LuoYuanke

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

(cherry picked from commit 8b69549dc5c5fa0f5f8632cde1c740bb2c7d8957)

[X86][FP16] Fix vector_shuffle and lowering without f16c feature problems

The problem Alexander reported on D127982 was caused by an optimization
for AVX512-FP16 instruction. We must limit it to the feature enabled only.

During the investigation, I found we didn't expand for fp_round/fp_extend
without F16C. This may result runtime crash, so change them too.

Reviewed By: RKSimon

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

(cherry picked from commit 23021d4d8c6b2c7cbb3ebe1be61cface0c52f80a)

[clang-tidy][docs] Fixed page title for abseil-no-internal-dependencies check documentation

It seems that documentation for abseil-no-internal-dependencies has invalid title.
This can be checked by looking at the actual web-site - https://clang.llvm.org/extra/clang-tidy/checks/abseil/no-internal-dependencies.html
There is redundant "subl.. title:: clang-tidy - abseil-no-internal-dependencies" paragraph in the beginning.

Reviewed By: njames93, sylvestre.ledru

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

(cherry picked from commit 6c7b049f6eb78edf83506a858c7b211a7c70afd8)

[X86] Add RDPRU instruction CPUID bit masks

As mentioned on D128934 - we weren't including the CPUID bit handling for the RDPRU instruction

AMD's APMv3 (24594) lists it as CPUID Fn8000_0008_EBX Bit#4

(cherry picked from commit 08a880509e4f7ca8d346dce42fe7528c3a33f22c)

[clang][X86] Add RDPRU predefined macro tests for znver2/znver3 targets

These were missed in D128934

(cherry picked from commit 6e19e6ce36e44554ac9fbf8b2780de05e922c849)

[libcxx] [test] Fix max_size.pass.cpp for PowerPC targets

This patch fixes the max_size.pass.cpp test for PowerPC targets, depending on
endianness.

We will exhibit the full_size() behaviour for little endian
(where __endian_factor = 2 ), and the half_size() behaviour for
big endian (where __endian_factor = 1).

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

(cherry picked from commit e2e9e2ce8efd12f0f2b7a12be113d4241706ddf2)

[OpenMP][FIX] Ensure __kmpc_kernel_parallel is reachable

The problem is we create the call to __kmpc_kernel_parallel in the
openmp-opt pass but while we optimize the code, the call is not there
yet. Thus, we assume we never reach it from __kmpc_target_deinit. That
allows us to remove the store in there (`ParallelRegionFn = nullptr`),
which leads to bad results later on.

This is a shortstop solution until we come up with something better.

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

(cherry picked from commit a8cda3290944687b4fd0138e63cd980ea497a438)

[Clang][OpenMP] Fix the issue that `llvm.lifetime.end` is emitted too early for variables captured in linear clause

Currently if an OpenMP program uses `linear` clause, and is compiled with
optimization, `llvm.lifetime.end` for variables listed in `linear` clause are
emitted too early such that there could still be uses after that. Let's take the
following code as example:
```
// loop.c
int j;
int *u;

void loop(int n) {
  int i;
  for (i = 0; i < n; ++i) {
    ++j;
    u = &j;
  }
}
```
We compile using the command:
```
clang -cc1 -fopenmp-simd -O3 -x c -triple x86_64-apple-darwin10 -emit-llvm loop.c -o loop.ll
```
The following IR (simplified) will be generated:
```
@j = local_unnamed_addr global i32 0, align 4
@u = local_unnamed_addr global ptr null, align 8

define void @loop(i32 noundef %n) local_unnamed_addr {
entry:
  %j = alloca i32, align 4
  %cmp = icmp sgt i32 %n, 0
  br i1 %cmp, label %simd.if.then, label %simd.if.end

simd.if.then:                                     ; preds = %entry
  call void @llvm.lifetime.start.p0(i64 4, ptr nonnull %j)
  store ptr %j, ptr @u, align 8
  call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
  %0 = load i32, ptr %j, align 4
  store i32 %0, ptr @j, align 4
  br label %simd.if.end

simd.if.end:                                      ; preds = %simd.if.then, %entry
  ret void
}
```
The most important part is:
```
  call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
  %0 = load i32, ptr %j, align 4
  store i32 %0, ptr @j, align 4
```
`%j` is still loaded after `@llvm.lifetime.end.p0(i64 4, ptr nonnull %j)`. This
could cause the backend incorrectly optimizes the code and further generates
incorrect code. The root cause is, when we emit a construct that could have
`linear` clause, it usually has the following pattern:
```
EmitOMPLinearClauseInit(S)
{
  OMPPrivateScope LoopScope(*this);
  ...
  EmitOMPLinearClause(S, LoopScope);
  ...
  (void)LoopScope.Privatize();
  ...
}
EmitOMPLinearClauseFinal(S, [](CodeGenFunction &) { return nullptr; });
```
Variables that need to be privatized are added into `LoopScope`, which also
serves as a RAII object. When `LoopScope` is destructed and if optimization is
enabled, a `@llvm.lifetime.end` is also emitted for each privatized variable.
However, the writing back to original variables in `linear` clause happens after
the scope in `EmitOMPLinearClauseFinal`, causing the issue we see above.

A quick "fix" seems to be, moving `EmitOMPLinearClauseFinal` inside the scope.
However, it doesn't work. That's because the local variable map has been updated
by `LoopScope` such that a variable declaration is mapped to the privatized
variable, instead of the actual one. In that way, the following code will be
generated:
```
  %0 = load i32, ptr %j, align 4
  store i32 %0, ptr %j, align 4
  call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
```
Well, now the life time is correct, but apparently the writing back is broken.

In this patch, a new function `OMPPrivateScope::restoreMap` is added and called
before calling `EmitOMPLinearClauseFinal`. This can make sure that
`EmitOMPLinearClauseFinal` can find the orignal varaibls to write back.

Fixes #56913.

Reviewed By: ABataev

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

(cherry picked from commit e21202dac18ed7f718d26a0e131f96b399b4891c)

[clang][AArch64][SVE] Change SVE_VECTOR_OPERATORS macro for VLA vectors

The __ARM_FEATURE_SVE_VECTOR_OPERATORS macro should be changed to
indicate that this feature is now supported on VLA vectors as well as
VLS vectors. There is a complementary PR to the ACLE spec here
https://github.com/ARM-software/acle/pull/213

Reviewed By: peterwaller-arm

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

(cherry picked from commit 13a784f368ef062a7bd652829bcf8bbdd94dc659)

[clang][AArch64][SVE] Clarify documentation for sizeof operator on SVE

Previously the table in LanguageExtensions said that sizeof worked on
SVE types but this is only correct for fixed-length vectors so a
clarification has been added.

(cherry picked from commit bbb30bd54a6447702f9f59a2ae4c478eb7133ae0)

[clang] Correct documentation for NEON and SVE operator support

Previously the language extension documentation didn't mention SVE and
was incomplete in listing the C/C++ operators supported on NEON. This
corrects the documentation to be in line with the implementation.

(cherry picked from commit e4642d78a89930720bc84a4775614c45327bc0dc)

[clang][AArch64][SVE] Add unary +/- operators for SVE types

This patch enables the unary promotion and negation operators on
SVE types.

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

(cherry picked from commit 286d59ef6f7118c8a0600f3d281593700528a5d3)

Fix assert during the call to getCanonicalDecl.
https://github.com/llvm/llvm-project/issues/56884

The root problem is in isOpenMPRebuildMemberExpr, it is only need to rebuild
for field expression.  No need for member function call.

The fix is to check field for member expression and skip rebuild for member
function call.

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

(cherry picked from commit a7bca18bc50cd2483fded0c77706980b2721ce6a)

[mlir][sparse] Refine f695554a2a55 wording a bit and fix the double conversion I broke with aggressive copy&paste

(cherry picked from commit 726719e970abb6d6fe014ed96f5ca838807dd840)

[mlir][sparse] Use the correct ABI on x86 and re-enable tests

c7ec6e19d5446a448f888b33f66316cf2ec6ecae made LLVM adhere to the x86
psABI and pass bf16 in SSE registers instead of GPRs. This breaks the
custom versions of runtime functions we have for bf16 conversion. A
great fix for this would be to use __bf16 types instead which carry the
right ABI, but that type isn't widely available.

Instead just pretend it's a 32 bit float on the ABI boundary and
carefully cast it to the right type.

Fixes #57042

(cherry picked from commit f695554a2a5550ae40da35af9ac22bfcca5db09a)

[mlir][sparse][bf16] disable two bf16 tests

Supposedly our ABI issues were fixed, per issue:
https://github.com/llvm/llvm-project/issues/55992

However, with a recent changes to bf16, these tests
fail again; not sure why yet:
https://reviews.llvm.org/D130832
https://lab.llvm.org/buildbot/#/builders/61/builds/30600

So we disable the tests for now. Issue is tracked in:
https://github.com/llvm/llvm-project/issues/57042

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

(cherry picked from commit 6b7459115f7b1c43f81ad8dfb5da9d206d3b1e06)

[compiler-rt][BF16] Provide __truncdfbf2 and __truncsfbf2 only when __bf16 is available

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

(cherry picked from commit f061cfb31730b72b7d8920bb4a306a1d2ce7f2e4)

[X86][BF16] Enable __bf16 for x86 targets.

X86 psABI has updated to support __bf16 type, the ABI of which is the
same as FP16. See https://discourse.llvm.org/t/patch-add-optional-bfloat16-support/63149

Reviewed By: pengfei

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

(cherry picked from commit e4888a37d36780872d685c68ef8b26b2e14d6d39)

[X86][BF16] Make backend type bf16 to follow the psABI

X86 psABI has updated to support __bf16 type, the ABI of which is the
same as FP16. See https://discourse.llvm.org/t/patch-add-optional-bfloat16-support/63149

This is an alternative of D129858, which has less code modification and
supports the vector type as well.

Reviewed By: LuoYuanke

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

(cherry picked from commit c7ec6e19d5446a448f888b33f66316cf2ec6ecae)

[LLD] [COFF] Add support for a new, mingw specific embedded directive -exclude-symbols:

This is an entirely new embedded directive - extending the GNU ld
command line option --exclude-symbols to be usable in embedded
directives too.

(GNU ld.bfd also got support for the same new directive, currently in
the latest git version, after the 2.39 branch.)

This works as an inverse to the regular embedded dllexport directives,
for cases when autoexport of all eligible symbols is performed.

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

(cherry picked from commit 5d513ef6cf4646e64bbb1d5f8610afd530964588)

[COFF] Change a llvm::StringSet<> to llvm::DenseSet<StringRef>. NFC

The former stores strings and is therefore more expensive.

(cherry picked from commit dfe2a3f3eb92b6a94453a74f3f0a4552f6965fcc)

[LLD] [MinGW] Implement the --exclude-symbols option

This adds support for the existing GNU ld command line option, which
allows excluding individual symbols from autoexport (when linking a
DLL and no symbols are marked explicitly as dllexported).

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

(cherry picked from commit d1da6469f9ea9b078276ee2e098241f0440468be)

[libcxx] [test] Merge the experimental-lib-exports testcases into static-lib-exports

Since bb939931a1adb9a47a2de13c359d6a72aeb277c8, the c++experimental
library is always built, so these tested files should always be built
(even if they aren't used in tests).

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

(cherry picked from commit b8717d19cfd49bfdbd462ea42cd94b94959e4feb)

[libc++] Add missing includes of <cstddef>

(cherry picked from commit b1009bbd9e3d5acd85e92cb7f9a1109d2e72967c)

[libc++] Make __libcpp_verbose_abort [[noreturn]]

This will allow using it in functions that are [[noreturn]] themselves.

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

(cherry picked from commit f5738c51452f90d7f33963d1c0c6f8e7f3d801e3)

[libc++][ranges] Sets ranges feature-test macro.

D131234 marked the ranges papers as complete, but it didn't set the
feature-test macro.

Reviewed By: ldionne, var-const, #libc

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

(cherry picked from commit 195287d90afb1b97a0fb869da501370e7c3e67c6)

[libc++][NFC] Fix signature of main in test

(cherry picked from commit 27442728cd2e28bfaf0f2d89ad6378b4377e9c66)

[libc++] Add missing <stdbool.h> to the modulemap

It used to be defined by the compiler, but libc++ now provides it.

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

(cherry picked from commit 0a5c344a84a452452185f3a6bd7d7679a42abb42)

Change prototype merging error into a warning for builtins

As was observed in https://reviews.llvm.org/D123627#3707635, it's
confusing that a user can write:
```
float rintf(void) {}
```
and get a warning, but writing:
```
float rintf() {}
```
gives an error. This patch changes the behavior so that both are
warnings, so that users who have functions which conflict with a
builtin identifier can still use that identifier as they wish.

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

(cherry picked from commit 4c02ab8c9742f6c32b17f49a306b3b072486f5c5)

[AArch64][LoopVectorize] Introduce trip count minimal value threshold to ignore tail-folding.

After D121595 was commited, I noticed regressions assosicated with small trip
count numbersvectorisation by tail folding with scalable vectors. As a solution
for those issues I propose to introduce the minimal trip count threshold value.

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

(cherry picked from commit cab6cd68340255be241b7cf169c67a1899ced115)

[clang] Require strict matches for defines for PCH in GCC style directories

When clang includes a PCH, it tolerates some amount of differences
between the defines used when creating and when including the PCH
- this seems to be intentionally allowed in
c379c072405f39bca1d3552408fc0427328e8b6d (and later extended in
b63687519610a73dd565be1fec28332211b4df5b).

When using a PCH (or when picking a PCH out of a directory containing
multiple candidates) Clang used to accept the header if there were
defines on the command line when creating the PCH that are missing
when using the PCH, or vice versa, defines only set when using the
PCH.

The only cases where Clang explicitly rejected the use of a PCH
is if there was an explicit conflict between the options, e.g.
-DFOO=1 vs -DFOO=2, or -DFOO vs -UFOO.

The latter commit added a FIXME that we really should check whether
mismatched defines actually were used somewhere in the PCH, so that
the define would affect the outcome. This FIXME has stood unaddressed
since 2012.

This differs from GCC, which rejects PCH files if the defines differ
at all.

When explicitly including a single PCH file, the relaxed policy
of allowing minor differences is harmless for correct use cases
(but may fail to diagnose mismtaches), and potentially allow using
PCHs in wider cases (where the user intentionally know that the
differences in defines are harmless for the PCH).

However, for GCC style PCH directories, with a directory containing
multiple PCH variants and the compiler should pick the correct match
out of them, Clang's relaxed logic was problematic. The directory
could contain two otherwise identical PCHs, but one built with -DFOO
and one without. When attempting to include a PCH and iterating over
the candidates in the directory, Clang would essentially pick the
first one out of the two, even if there existed a better, exact
match in the directory.

Keep the relaxed checking when specificlly including one named
PCH file, but require strict matches when trying to pick the right
candidate out of a GCC style directory with alternatives.

This fixes https://github.com/lhmouse/mcfgthread/issues/63.

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

(cherry picked from commit c843c921a1a385bb805b2338d980436c94f83f19)

[RelLookupTableConverter] Bail on invalid pointer size (x32)

The RelLookupTableConverter pass currently only supports 64-bit
pointers.  This is currently enforced using an isArch64Bit() check
on the target triple. However, we consider x32 to be a 64-bit target,
even though the pointers are 32-bit. (And independently of that
specific example, there may be address spaces with different pointer
sizes.)

As such, add an additional guard for the size of the pointers that
are actually part of the lookup table.

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

(cherry picked from commit 4ac00789e1b30145ec3cacc4b2a66cb755ff9e4a)

[Attributor][FIX] Visit same instructions with different scopes

If we collect potential values we need to visit a value even if we have
seen it before if the scope is different. The scope is part of the
result after all. Test included.

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

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

(cherry picked from commit b65471d7152d15790ae599326da86b7e6cfb4580)

[Libomptarget][CUDA] Check CUDA compatibilty correctly

We recently added support for multi-architecture binaries in
libomptarget. This is done by extracting the architecture from the
embedded image and comparing it with the major and minor version
supported by the current CUDA installation. Previously we just compared
these directly, which was not correct for binary compatibility. The CUDA
documentation states that we can consider any image with an equivalent
major or a greater or equal to minor compatible with the current image.
Change the check to use this new logic in the CUDA plugin.

Fixes #57049

Reviewed By: jdoerfert, ye-luo

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

(cherry picked from commit fdbb15355e7977b914cbd7e753b5e909d735ad83)

[clang] add APValue type check in `TryPrintAsStringLiteral`

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

https://reviews.llvm.org/D115031 improved printing of non-type template
parameter args. But checking if the end of Inits is 0 without checking
if APValue is an integer, causes clang to segfault. This patch adds
the code to check the type. (May not be a proper bugfix.)

Reviewed By: aaron.ballman, lichray

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

(cherry picked from commit 55d3b79d159bab53b140860279486db8a1c0e4f3)

[RISCVInsertVSETVLI] Remove an unsound optimization

This fixes a bug reported privately by @craig.topper. Here's an example which illustrates the problem:

vsetivli a1, a0, e32, m1, ta, mu # both DefInfo and PrevInfo
vsetivli a2, a1, e32, m4, ta, mu

With the unsound result being:

vsetivli a1, a0, e32, m1, ta, mu
vsetivli a2, a0, e32, m4, ta, mu

Consider the case where this is running on a machine with VLEN=512,. For this case, the VLMAXs are 16 and 64 respectively.

Consider for a0 = 33. The correct result is: a1 = 16, and a2 = 16

After the unsound optimization: a1 = 16 and a2 = 33

This particular example used VLMAXs which differed by more than a power of two. With a difference of only one power of two, there's another form of this bug which involves the AVL < 2 x VLMAX special case, but that ones more complicated to construct as many examples turn out accidentally sound.

This patch takes the approach of simply removing the unsound optimization, but there are multiple sound sub-cases of it. I plan to return to at least a couple of them, but figured it was cleaner to remove the unsound optimization (for ease of backporting), and then review the new optimizations on their own.

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

(cherry picked from commit 9a9848f4b95895ad97d3dc117f0a94773dc1607f)

Revert "[clang] Pass FoundDecl to DeclRefExpr creator for operator overloads"

This reverts commit 4e94f6653150511de434fa7e29b684ae7f0e52b6.
See https://reviews.llvm.org/D129973#3698969 for reasoning.

(cherry picked from commit df48e3fbcc8be1f4c04bd97517d12e662f54de75)

[llvm-ranlib] Support more than one input file

BSD and GNU ranlib support more than one input file. Implement this.

While here, update OVERVIEW (Ranlib => ranlib) since "ranlib" is more common.
Remove "speed access" since the index has nothing to do with performance: it is
mandatory for GNU ld and gold but ignored for ld.lld (D119074).

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

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

(cherry picked from commit aa173573198e024b065c5f6523ce26bb865781b7)

[llvm-ar] Remove unused parameter. NFC

(cherry picked from commit 350f17ab52ec9df60095f7b7bccd49c429885ef7)

[libc++][format] Exposes basic-format-string

This paper was accepted during the last plenary and is intended to be
backported to LLVM 15. When backporting the release notes in the branch
should be updated too.

Note the feature-test macro isn't updated since this will change; three
papers have updated the same macro in the same plenary.

Implements:
- P2508R1 Exposing std::basic-format-string

Reviewed By: ldionne, #libc

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

(cherry picked from commit f712775dafdb221fdf73f38819fa9e618aec6b67)

[flang][test] Don't require .exe suffix.

The suffix is only added then the path the (lld-)link.exe is fully
resolved. Otherwise it may stay "link" or "lld-link".

On non-Windows platforms, lld-link also exists as a symbolic link to
lld, such that the full the path to lld-link might also be resolved
without .exe suffix in this case.

Note that CLANG_DEFAULT_LINKER could be set to other linkers such as
mold, in which case the test may still fail. This also applies to the
non-Windows tests that require "ld" in the linker name.

Fixes issue #56955

(cherry picked from commit 8c0979c8f7723306862b33583c6bdb1f4566a969)

[clangd] Add release notes

[DAG] Ensure Legal BUILD_VECTOR elements types in shuffle->And combine

D129150 added a combine from shuffles to And that creates a BUILD_VECTOR
of constant elements. We need to ensure that the elements are of a legal
type, to prevent asserts during lowering.

Fixes #56970.

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

(cherry picked from commit 061e0189a3dab6b1831a80d489ff1b15ad93aafb)

[ARM] Regenerate vector_store.ll tests. NFC

(cherry picked from commit f8d976171f2a1b7bf9268929f77904973edb0378)