[NFC][flang] Add FIXME for privatization of loop bounds in Bridge.cpp

There is post comment of adding TODO/FIXME for privatization of loop
bounds in D127137. D127137 fixes the bug in OpenMP firstprivate clause,
which should be refactored later according to the post comment. Add
FIXME for it.

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

[AggressiveInstCombine] check sqrt operand to allow more libcall->intrinsic transforms

This should fix issue #56383 (at least when compiled with -O3 because this pass is only
run at -O3 currently).

[AggressiveInstCombine] add tests for sqrt with known positive operand; NFC

[AArch64][SVE] Add Gather Index narrowing tests

[libc++][doc] Updates status documents.

Adds the papers and LWG issues voted in during the July 2022 plenary.

Note the updating of the project based statuses is left to the active
contributors of these projects.

Reviewed By: #libc, huixie90, philnik

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

[amdgpu][nfc] Fix build with a certan Clang version

It errors out in the Bazel CI:

AMDGPULowerModuleLDSPass.cpp:384:12: error: chosen constructor is
explicit in copy-initialization
    return {SGV, std::move(Map)};

Reviewed By: rupprecht

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

[NFC][flang] Remove the unused header in Bridge.cpp

The header file OpenMPDialect.h is added in Bridge.cpp in D130027,
but it is unused. Remove it.

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

Revert "[OpenMP] Remove noinline attributes in the device runtime"

The behaviour of this patch is not great, but it has some side-effects
that are required for OpenMPOpt to work. The problem is that when we use
`-mlink-builtin-bitcode` we only import used symbols from the runtime.
Then OpenMPOpt will insert calls to symbols that were not previously
included. This patch removed this implicit behaviour as these functions
were kept alive by the `noinline` simply because it kept calls to them
in the module. This caused regression in some tests that relied on some
OpenMPOpt passes without using LTO. Reverting for the LLVM15 release but
will try to fix it more correctly on main.

This reverts commit d61d72dae604c3258e25c00622b1a85861450303.

Fixes #56752

[LV] Add missing uses to test to make them more robust.

The changes ensure the VPPredInstPHIRecipes are actually used and cannot
be remove by VP-DCE.

[libLTO] Set data-sections by default in libLTO.

This patch changes legacy LTO to set data-sections by default. The user can
explicitly unset data-sections. The reason for this patch is to match the
behaviour of lld and gold plugin. Both lld and gold plugin have data-sections on
by default.

This patch also fixes the forwarding of the clang options -fno-data-sections and
-fno-function-sections to libLTO. Now, when -fno-data/function-sections are
specified in clang, -data/function-sections=0 will be passed to libLTO to
explicitly unset data/function-sections.

Reviewed By: w2yehia, MaskRay

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

[bazel] Port 5caa941f683270c3e5078ec46f208212b565c505

Revert "[libLTO] Set data-sections by default in libLTO."

This reverts commit f565444b486d49f84297c3a279ca24d785961ea8.

Revert "ManagedStatic: remove from ASTMatchersInternal.h"

This reverts commit 7132bcdc428d79258901af0156ace240952b6745.

It is the likely cause of a clang-tools-extra test regression. Reverting
until I can investigate what's going on.

[Bazel] Bump to v16.0.0, corresponding to llvmorg-16-init

[libLTO] Set data-sections by default in libLTO.

This patch changes legacy LTO to set data-sections by default. The user can
explicitly unset data-sections. The reason for this patch is to match the
behaviour of lld and gold plugin. Both lld and gold plugin have data-sections on
by default.

This patch also fixes the forwarding of the clang options -fno-data-sections and
-fno-function-sections to libLTO. Now, when -fno-data/function-sections are
specified in clang, -data/function-sections=0 will be passed to libLTO to
explicitly unset data/function-sections.

Reviewed By: w2yehia, MaskRay

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

[mlir][complex] Custom attribute comlex.number.

Add custom attribute for complex dialect. Although this commit does not have significant impact on the conversion framework, it will lead us to construct complex numbers in a readable and tidy manner.

Related discussion: https://reviews.llvm.org/D127476

Reviewed By: pifon2a, akuegel

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

[DAG] SimplifyDemandedBits - ensure we clear known One bits that AssertZext asserts are really known Zero

Matches ComputeKnownBits behaviour

Thanks to @uabelho for the fuzz regression report on D129765

ManagedStatic: remove from ASTMatchersInternal.h

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

clang: include ManagedStatic.h for llvm_shutdown

The code relied on ManagedStatic.h being included indirectly. This is
about to change as uses of ManagedStatic are removed throughout the
codebase.

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

ClangLinkerWrapper: explicitly #include <atomic>

This code relied on implicitly having std::atomic available via the
ManagedStatic.h header.

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

[mlir][LLVM] Fix incorrect GEP fold with struct constants

The fold in it's current state only checks whether the amount of dynamic indices is 1. This does however not check for the presence of any struct indices, leading to an incorrect fold.

This patch fixes that issue by checking that struct indices are 1, which in addition to the pre-existing check that dynamic indices are 1, guarantees that the single index is a dynamic one.

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

[lldb] Always use APFloat for FP dumping

The DumpDataExtractor function had two branches for printing floating
point values. One branch (APFloat) was used if we had a Target object
around and could query it for the appropriate semantics. If we didn't
have a Target, we used host operations to read and format the value.

This patch changes second path to use APFloat as well. To make it work,
I pick reasonable defaults for different byte size. Notably, I did not
include x87 long double in that list (as it is ambibuous and
architecture-specific). This exposed a bug where we were printing
register values using the target-less branch, even though the registers
definitely belong to a target, and we had it available. Fixing this
prompted the update of several tests for register values due to slightly
different floating point outputs.

The most dubious aspect of this patch is the change in
TypeSystemClang::GetFloatTypeSemantics to recognize `10` as a valid size
for x87 long double. This was necessary because because sizeof(long
double) on x86_64 is 16 even though it only holds 10 bytes of useful
data. This generalizes the hackaround present in the target-free branch
of the dumping function.

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

[trace] Add instruction control flow kind to JSON trace dumper's output

D128477 adds a '-k' flag which displays each instruction's control flow in the `thread trace dump instructions` command's non-json  output (ie no '-j' or '-J' flag)
This diff adds the instruction control flow kind to the `thread trace dump instructions` command's JSON output (ie '-j' or '-J' flag)

Test Plan:
Confirm "controlFlowKind" is present in JSON when '-k' is provided
```
(lldb) thread trace dump instructions -J -k
[
  {                                                                                                                                                                                                                                                                                 [141/1952]
    "id": 7755,
    "loadAddress": "0x400868",
    "module": "test.out",
    "symbol": "main",
    "mnemonic": "jmp",
    "controlFlowKind": "jump",
    "source": "/home/jakobjohnson/jakob-dev/test.cpp",
    "line": 41,
    "column": 29
  },
  {
    "id": 7753,
    "loadAddress": "0x7ffff7b54dab",
    "module": "libstdc++.so.6",
    "symbol": "std::ostream::flush()",
    "mnemonic": "retq",
    "controlFlowKind": "return"
  },
  {
    "id": 7752,
    "loadAddress": "0x7ffff7b54daa",
    "module": "libstdc++.so.6",
    "symbol": "std::ostream::flush()",
    "mnemonic": "popq",
    "controlFlowKind": "other"
  },
  ...
]
```
Confirm "controlFlowKind" is not present when '-k' isn't provided
```
(lldb) thread trace dump instructions -J
[
  {
    "id": 7755,
    "loadAddress": "0x400868",
    "module": "test.out",
    "symbol": "main",
    "mnemonic": "jmp",
    "source": "/home/jakobjohnson/jakob-dev/test.cpp",
    "line": 41,
    "column": 29
  },
  {
    "id": 7753,
    "loadAddress": "0x7ffff7b54dab",
    "module": "libstdc++.so.6",
    "symbol": "std::ostream::flush()",
    "mnemonic": "retq"
  },
  {
    "id": 7752,
    "loadAddress": "0x7ffff7b54daa",
    "module": "libstdc++.so.6",
    "symbol": "std::ostream::flush()",
    "mnemonic": "popq"
  },
```

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

[gn build] (semi-manually) port 6bdb15fe844c

Sinking or hoisting instructions between loops before fusion

Instructions between two adjacent loops will be hoisted above the first
loop, or sunk below the second to facilitate loop fusion. Hoisting will
be attempted for an instruction that dominates the first loop.
Otherwise, sinking this instructions will be attempted.

Instructions with side effects will not be considered for sinking or
hoisting. Hoisting/sinking of any instructions between loops will only
be performed if all the instructions can be moved. As well,
sinking/hoisting is considered for each instruction in isolation,
without taking into account sinking/hoisting decisions for other
instructions in the preheader.

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

[clang][ExtractAPI] Fix objc_property.m reference output

After landing 7f0387de4c600af185b2db8d748f530444fe03cd I forgot to update this
new test.

[CMake] Enable -z defs on Solaris

I wondered why I hadn't seen the link failures in D130571
<https://reviews.llvm.org/D130571> on Solaris/sparcv9 and found that
Solaris, unlike Linux, doesn't use `-Wl,-z,defs` when linking shared
objects.  The three affected shared objects indeed have undefined
references to several 64-bit atomics.

This patch will expose such issues in the future by defaulting to
`-Wl,-z,defs` on Solaris, as recommended in `ld(1)`.

Tested on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`.

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

[Sema] Return primary merged decl as canonical for concepts

Otherwise we get invalid results for ODR checks. See changed test for an
example: despite the fact that we merge the first concept, its **uses**
were considered different by `Profile`, leading to redefinition errors.

After this change, canonical decl for a concept can come from a
different module and may not be visible. This behavior looks suspicious,
but does not break any tests. We might want to add a mechanism to make
the canonical concept declaration visible if we find code that relies on
this invariant.

Additionally make sure we always merge with the canonical declaration to
avoid chains of merged concepts being reported as redefinitions. An
example was added to the test.

Also change the order of includes in the test. Importing a moduralized
header before its textual part causes the include guard macro to be
exported and the corresponding `#include` becomes a no-op.

Reviewed By: ChuanqiXu

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

[flang] Disable pipefail for tests for stdin input

We have seen the llvm test fail every so often on our bots:
https://lab.llvm.org/buildbot/#/builders/173/builds/6711

This happens because `flang-new -fc1 -S` does not wait for the
pipe to finish being written to/does not read out all the content.
You can see this in the output, cat comes after flang:
+ /home/tcwg-buildbot/worker/flang-aarch64-release/build/bin/not /home/tcwg-buildbot/worker/flang-aarch64-release/build/bin/flang-new -fc1 -S - -o -
+ cat /home/tcwg-buildbot/worker/flang-aarch64-release/llvm-project/flang/test/Driver/input-from-stdin-llvm.ll
error: Invalid input type - expecting a Fortran file

This means that cat gets SIGPIPE which causes it to exit with
code 141 and that's the final result due to pipefail.

flang isn't wrong to exit early (I think some modes of grep also do this)
and we only care about flang's exit code. So disable pipefail for
the stdin testing.

Reviewed By: awarzynski

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

[compiler-rt][Sanitizer] Link sanitizer libs with -latomic on SPARC

When building on Linux/sparc64, the 32-bit `libclang_rt.asan.so`,
`libclang_rt.ubsan_minimal.so`, and `libclang_rt.ubsan_standalone.so`
failed to link with undefined references to 64-bit atomics, which `clang`
cannot inline.  Even D130569 <https://reviews.llvm.org/D130569> didn't help
because those libraries are linked with `-nodefaultlibs`, so dependent
libraries need to be added explicitly.

That's what this patch does.

Tested on `sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11`.

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

[flang] Single entry point for GET_COMMAND_ARGUMENT

This patch refactors the runtime support for GET_COMMAND_ARGUMENT to
have a single entry point instead of 2. It also updates lowering
accordingly.

This makes it easier to handle dynamically optional arguments. See also
https://reviews.llvm.org/D118777

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

[RISCV]Enable isIntDivCheap when attribute is minsize

Don't expand divisions by constants when attribute is minsize.

Reviewed By: craig.topper

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

[Support] Handle SPARC in sys::getHostCPUName

While working on D118450 <https://reviews.llvm.org/D118450>, I noticed that
`sys::getHostCPUName` lacks SPARC support.

This patch implements it.  The code is taken from/inspired by GCC's
`gcc/config/sparc/driver-sparc.cc`.  There's one caveat: since LLVM, unlike
GCC, doesn't support the SPARC-M7, -S7, and -M8 CPUs, I map all those to
the latest supported one (UltraSparc T4/`niagara4`).

Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu` by
running `savcov --version` on

- Netra SPARC S7-2 (SPARC-S7, Solaris 11.4)
- SPARC T5-2 (SPARC T5, Solaris 11.4)
- SPARC Enterprise T5220 (UltraSPARC T2, Solaris 11.3)
- SPARC T5 (UltraSPARC T5, Debian sid)
- SPARC T3 (UltraSPARC T3, Debian sid)
- SPARC Enterprise T5220 (Debian sid)

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

[clang][ExtractAPI] Ensure that class properties have a kind of "Type Property"

Generated symbol graphs should distinguish between type properties and instance
properties.

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

[clang][ExtractAPI] Add a space between type and name in property declaration fragments

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

[DAG] SimplifyDemandedBits - don't early-out for multiple use values

SimplifyDemandedBits currently early-outs for multi-use values beyond the root node (just returning the knownbits), which is missing a number of optimizations as there are plenty of cases where we can still simplify when initially demanding all elements/bits.

@lenary has confirmed that the test cases in aea-erratum-fix.ll need refactoring and the current increase codegen is not a major concern.

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

[mlir] update Bazel for e99fae899710b041994cef4beb6764f8dfbe8ef0

[clang-tidy] Add execute perms back to add_new_check script

[CSKY] Fix the btsti16 instruction missing in generic processor

Normally, generic processor does not have any SubtargetFeature. And it
can just generate most basic instructions which have no Predicates to
guard.

But it needs to enbale predicate for the btsti16 instruction as one of the most basic instructions.
Or the generic processor can't finish codegen process. So Add FeatureBTST16 SubtargetFeature to generic ProcessorModel.

[ARM] Test more atomic sizes with +atomics-32 feature (NFC)

Check that 8-bit and 16-bit atomics also work as expected. Also
fix the alignment on the 64-bit tests -- testing unaligned atomics
wasn't intended here.

Update ProgrammersManual STL docs

The SGI page doesn't exist anymore and isn't really relevant at this day
and age.

While at it, added the "other" main C++ website and moved all URLs to
HTTPS.

[clang] Implement ElaboratedType sugaring for types written bare

Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which goes against the intent that
we should produce an AST which retains enough details to recover how things are
written.

The lack of this sugar is incompatible with the intent of the type printer
default policy, which is to print types as written, but to fall back and print
them fully qualified when they are desugared.

An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still
requires pointer alignment due to pre-existing bug in the TypeLoc buffer
handling.

---

Troubleshooting list to deal with any breakage seen with this patch:

1) The most likely effect one would see by this patch is a change in how
   a type is printed. The type printer will, by design and default,
   print types as written. There are customization options there, but
   not that many, and they mainly apply to how to print a type that we
   somehow failed to track how it was written. This patch fixes a
   problem where we failed to distinguish between a type
   that was written without any elaborated-type qualifiers,
   such as a 'struct'/'class' tags and name spacifiers such as 'std::',
   and one that has been stripped of any 'metadata' that identifies such,
   the so called canonical types.
   Example:
   ```
   namespace foo {
     struct A {};
     A a;
   };
   ```
   If one were to print the type of `foo::a`, prior to this patch, this
   would result in `foo::A`. This is how the type printer would have,
   by default, printed the canonical type of A as well.
   As soon as you add any name qualifiers to A, the type printer would
   suddenly start accurately printing the type as written. This patch
   will make it print it accurately even when written without
   qualifiers, so we will just print `A` for the initial example, as
   the user did not really write that `foo::` namespace qualifier.

2) This patch could expose a bug in some AST matcher. Matching types
   is harder to get right when there is sugar involved. For example,
   if you want to match a type against being a pointer to some type A,
   then you have to account for getting a type that is sugar for a
   pointer to A, or being a pointer to sugar to A, or both! Usually
   you would get the second part wrong, and this would work for a
   very simple test where you don't use any name qualifiers, but
   you would discover is broken when you do. The usual fix is to
   either use the matcher which strips sugar, which is annoying
   to use as for example if you match an N level pointer, you have
   to put N+1 such matchers in there, beginning to end and between
   all those levels. But in a lot of cases, if the property you want
   to match is present in the canonical type, it's easier and faster
   to just match on that... This goes with what is said in 1), if
   you want to match against the name of a type, and you want
   the name string to be something stable, perhaps matching on
   the name of the canonical type is the better choice.

3) This patch could expose a bug in how you get the source range of some
   TypeLoc. For some reason, a lot of code is using getLocalSourceRange(),
   which only looks at the given TypeLoc node. This patch introduces a new,
   and more common TypeLoc node which contains no source locations on itself.
   This is not an inovation here, and some other, more rare TypeLoc nodes could
   also have this property, but if you use getLocalSourceRange on them, it's not
   going to return any valid locations, because it doesn't have any. The right fix
   here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive
   into the inner TypeLoc to get the source range if it doesn't find it on the
   top level one. You can use getLocalSourceRange if you are really into
   micro-optimizations and you have some outside knowledge that the TypeLocs you are
   dealing with will always include some source location.

4) Exposed a bug somewhere in the use of the normal clang type class API, where you
   have some type, you want to see if that type is some particular kind, you try a
   `dyn_cast` such as `dyn_cast<TypedefType>` and that fails because now you have an
   ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match.
   Again, like 2), this would usually have been tested poorly with some simple tests with
   no qualifications, and would have been broken had there been any other kind of type sugar,
   be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType.
   The usual fix here is to use `getAs` instead of `dyn_cast`, which will look deeper
   into the type. Or use `getAsAdjusted` when dealing with TypeLocs.
   For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast.

5) It could be a bug in this patch perhaps.

Let me know if you need any help!

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D112374

[pseudo] Fix initializer of string table

Apparently new string[/*no size*/]{"foo", "bar"} is a clang/gcc extension?

[flang][NFC] Unify check prefixes in `abstract-results.fir` test

Now the prefixes have the same length
and they'll be easier to distinguish when
`GlobalOp` tests will be added

Depends on D129778

Reviewed By: clementval

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

[flang] Generalize `AbstractResultOpt` pass

This change decouples common functionality for convering abstract
results, so it can be reused later.

Depends on D129485

Reviewed By: clementval, jeanPerier

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

[mlir] more aggressive folding in tiling/fusion transformations

Combine the recently added utilities for folded-by-construction affine
operations with the attribute-based Range to enable more folding. This
decreases the amount of emitted code but has little effect on test
precisely because the tests are not checking for the spurious constants.
The difference in the shape of affine maps comes from the internals of
affine folding.

Depends on D129633

Reviewed By: nicolasvasilache

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

[mlir] Make ViewLikeInterface Range work with attributes

While most of methods in ViewLikeInterface accept an `OpFoldResult` for
the offset/size/stride that may be static, represented as `Attribute`,
or dynamic, represented as `Value`, the `Range` abstraction only
accepted `Values`. This can often lead to known-constant
offset/size/strides being materialized into constant operations and
hinder further constant propagation without explicitly running the
constant folding pass. This often leads to a more complicated than
necessary addressing code being emitted. Switch `Range` to use
`OpFoldResult`. Code that uses `Range` currently keeps materializing the
constants to minimize the effect of this change on the IR. Further
commits will make use of this.

Reviewed By: nicolasvasilache, mravishankar

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

[mlir] Partially port splitting transform to TilingInterface

The structured op splitting transformation is conceptually similar to
tiling in the sense that it decomposes the iteration space of the
original op into several parts. Therefore, it is possible to implement
it using the TilingInterface to operate on iteration spaces and their
parts. However, the implementation also requires to pass updated input
operands, which is not supported by the interface, so the implementation
currently remains Linalg-specific.

Reviewed By: mravishankar

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

Revert "[Debuginfo][llvm-dwarfutil] Add check for unsupported debug sections."

This reverts commit 0d191b7553e7efbf7ce57c77274b83c15b681933.

Emit a simple StackSizesSection on PS4.

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

Disable stack-sizes section by default for PS4.

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

[ARM] Correct features on pacbti instructions.

Given a patch like D129506, using instructions not valid for the current
feature set becomes an error. This updates the Arm hint-space
instructions for pac/bti to require thumbv7m as opposed to 8.1-m.main, to
make them valid when compiling for thumbv7m with -mbranch-protection.

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

[mlir] Apply ClangTidyPerformance findings (NFC)

[ARM] Add target feature to force 32-bit atomics

This adds a +atomic-32 target feature, which instructs LLVM to assume
that lock-free 32-bit atomics are available for this target, even
if they usually wouldn't be.

If only atomic loads/stores are used, then this won't emit libcalls.
If atomic CAS is used, then the user is responsible for providing
any necessary __sync implementations (e.g. by masking interrupts
for single-core privileged use cases).

See https://reviews.llvm.org/D120026#3674333 for context on this
change. The tl;dr is that the thumbv6m target in Rust has
historically made atomic load/store only available, which is
incompatible with the change from D120026, which switched these to
use libatomic.

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

[AArch64][GlobalISel] Lower vector G_CTTZ.

Fixes issue 56398

[pseudo] Add dangling-else guard to missing if-statement variants

[pseudo] Remove dead header

This was an earlier draft of Language.h that got committed accidentally

[pseudo] Reorganize CXX.h enums

- Place rules under rule::lhs::rhs__rhs__rhs
- Change mangling of keywords to ALL_CAPS (needed to turn keywords that appear
  alone on RHS into valid identifiers)
- Make enums implicitly convertible to underlying type (though still scoped,
  using alias tricks)

In principle this lets us exhaustively write a switch over all rules of a NT:
  switch ((rule::declarator)N->rule()) {
    case rule::declarator::noptr_declarator:
      ...
  }
In practice we don't do this anywhere yet as we're often switching over multiple
nonterminal kinds at once.

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

Update checks legalize-cttz.mir test before change.

[NFC] [C++20] [Modules] Use Sema::isModuleUnitOfCurrentTU to simplify the code

[clang] Make parts of index test optional

Reason is that the test behaves differently in clang-ppc64-aix in that the optional part appears in the output.

[NFC] [C++20] [Modules] Use Sema::isCurrentModulePurview() to simplify the codes

[NFC] Convert a dyn_cast<> to an isa<>

Bump the trunk major version to 16

Inline function calls.

Fix unused variable in non-assert builds after
300fbf56f89aebbe2ef9ed490066bab23e5356d1

[lld-macho] Fix -bitcode_process_mode arg type

This is still undocumented and unsupported, but if someone passed it
before you would end up with a missing file error since this takes an
argument that wouldn't be handled.

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

[libc++][ranges] Fix the CI.

[clang][AIX] Add option to control quadword lock free atomics ABI on AIX

We are supporting quadword lock free atomics on AIX. For the situation that users on AIX are using a libatomic that is lock-based for quadword types, we can't enable quadword lock free atomics by default on AIX in case user's new code and existing code accessing the same shared atomic quadword variable, we can't guarentee atomicity. So we need an option to enable quadword lock free atomics on AIX, thus we can build a quadword lock-free libatomic(also for advanced users considering atomic performance critical) for users to make the transition smooth.

Reviewed By: shchenz

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

[ASan] Use stack safety analysis to optimize allocas instrumentation.

Added alloca optimization which was missed during the implemenation of D112098.

Reviewed By: vitalybuka

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

[asan][test] Check for __asan_stack_malloc

[amdgpu][nfc] Separate processUsedLDS into independent pieces, rename it

[Polly] Insert !dbg metadata for emitted CallInsts.

The IR Verifier requires that every call instruction to an inlineable
function (among other things, its implementation must be visible in the
translation unit) must also have !dbg metadata attached to it. When
parallelizing, Polly emits calls to OpenMP runtime function out of thin
air, or at least not directly derived from a bounded list of previous
instruction. While we could search for instructions in the SCoP that has
some debug info attached to it, there is no guarantee that we find any.
Our solution is to generate a new DILocation that points to line 0 to
represent optimized code.

The OpenMP function implementation is usually not available in the
user's translation unit, but can become visible in an LTO build. For
the bug to appear, libomp must also be built with debug symbols.

IMHO, the IR verifier rule is too strict. Runtime functions can
also be inserted by other optimization passes, such as
LoopIdiomRecognize. When inserting a call to e.g. memset, it uses the
DebugLoc from a StoreInst from the unoptimized code. It is not
required to have !dbg metadata attached either.

Fixes #56692

[amdgpu][nfc] Extract kernel annotation from processUsedLDS

workflows: Use sccache to speed up CI builds

Reviewed By: asl

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

[asan][test] Cleanup asan-stack-safety.ll test

Import CI tests from the release branch

The tests still only run on pushes or pull requests for the release
branch, but having it in the main branch means we don't have to copy
the tests every time we create a new release branch.

Reviewed By: asl

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

[libc++][NFC] Add checks for lifetime issues in classic algorithms.

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

[libc++][ranges] Implement `ranges::is_heap{,_until}`.

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

Add string conversion for InstructionControlFlowKind enum

Refactor the string conversion of the `lldb::InstructionControlFlowKind` enum out
of `Instruction::Dump` to enable reuse of this logic by the
JSON TraceDumper (to be implemented in separate diff).

Will coordinate the landing of this change with D130320 since there will be a minor merge conflict between
these changes.

Test Plan:
Run unittests
```
> ninja check-lldb
[4/5] Running lldb unit test suite

Testing Time: 10.13s
  Passed: 1084
```

Verify '-k' flag's output
```
(lldb) thread trace dump instructions -k
thread #1: tid = 1375377
  libstdc++.so.6`std::ostream::flush() + 43
    7048: 0x00007ffff7b54dab    return      retq
    7047: 0x00007ffff7b54daa    other       popq   %rbx
    7046: 0x00007ffff7b54da7    other       movq   %rbx, %rax
    7045: 0x00007ffff7b54da5    cond jump   je     0x11adb0                  ; <+48>
    7044: 0x00007ffff7b54da2    other       cmpl   $-0x1, %eax
  libc.so.6`_IO_fflush + 249
    7043: 0x00007ffff7161729    return      retq
    7042: 0x00007ffff7161728    other       popq   %rbp
    7041: 0x00007ffff7161727    other       popq   %rbx
    7040: 0x00007ffff7161725    other       movl   %edx, %eax
    7039: 0x00007ffff7161721    other       addq   $0x8, %rsp
    7038: 0x00007ffff7161709    cond jump   je     0x87721                   ; <+241>
    7037: 0x00007ffff7161707    other       decl   (%rsi)
    7036: 0x00007ffff71616fe    cond jump   je     0x87707                   ; <+215>
    7035: 0x00007ffff71616f7    other       cmpl   $0x0, 0x33de92(%rip)      ; __libc_multiple_threads
    7034: 0x00007ffff71616ef    other       movq   $0x0, 0x8(%rsi)
    7033: 0x00007ffff71616ed    cond jump   jne    0x87721                   ; <+241>
    7032: 0x00007ffff71616e9    other       subl   $0x1, 0x4(%rsi)
    7031: 0x00007ffff71616e2    other       movq   0x88(%rbx), %rsi
    7030: 0x00007ffff71616e0    cond jump   jne    0x87721                   ; <+241>
    7029: 0x00007ffff71616da    other       testl  $0x8000, (%rbx)           ; imm = 0x8000
```

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

[libc++][ranges] Make sure all range algorithms support differing projection types:

- for all algorithms taking more than one range, add a `robust` test to
  check the case where the ranges have different value types and the
  given projections are different, with each projection applying to
  a different value type;
- fix `ranges::include` to apply the correct projection to each range.

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

[libc++][ranges] Implement `ranges::generate{,_n}`.

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

Revert "[Support] Workaround compiler bug in MSVC"

This reverts commit ec8f4fd68cd401a0ba41bb160d6acce670486fab.

This caused a failure in the mlir-windows bot.

workflows: Add GitHub action for automating some release tasks

For each release tag, this action will create a new release on GitHub,
and for each -final tag, this action will build the documentation and
upload it to GitHub.

Reviewed By: hans, kwk

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

github: Automatically assign reviewers for backport requests

When there is a backport request, the GitHub Action that handles the
backport will now automatically assign the issue to the user(s) who
approved the commit in Phabricator and create an issue comment asking
them to review the request.

Reviewed By: thieta, kwk

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

[CodeGen] Fixed ambiguous symbol ExtAddrMode in case of NDEBUG and LLVM_ENABLE_DUMP

This patch fixes the following error with MSVC 16.9.2 in case of NDEBUG and LLVM_ENABLE_DUMP:
llvm/lib/CodeGen/CodeGenPrepare.cpp(2581): error C2872: 'ExtAddrMode': ambiguous symbol
llvm/include/llvm/CodeGen/TargetInstrInfo.h(86): note: could be 'llvm::ExtAddrMode'
llvm/lib/CodeGen/CodeGenPrepare.cpp(2447): note: or '`anonymous-namespace'::ExtAddrMode'
llvm/lib/CodeGen/CodeGenPrepare.cpp(2581): error C2039: 'print': is not a member of 'llvm::ExtAddrMode'

Reviewed By: aaron.ballman

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

github: Fix release automation /branch command with new repo

We started using the llvm/llvm-project-release-prs repo for
backport pull requests, but since this repo is not a fork of
llvm/llvm-project it will reject pull requests from other repos. In
order to fix this, when ever someone uses the /branch command to request
a branch be merged into the release branch, we first copy the branch to
the llvm-project-release-prs repo and then create the pull request.

Reviewed By: thieta

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

[ELF] addDependentLibrary: fix a use-after-free bug in archiveName

[mlir] Refactor SubElementInterface replace support

The current support was essentially the amount necessary
to support replacing SymbolRefAttrs, but suffers from various
deficiencies (both ergonomic and functional):

* Replace crashes if unsupported
 This makes it really hard to use safely, given that you don't know
 if you are going to crash or not when using it.

* Types aren't supported
This seems like a simple missed addition when the attribute replacement
support was originally added.

* The ergonomics are weird
It currently uses an index based replacement, which makes the implementations
quite clunky.

This commit refactors support to be a bit more ergonomic, and also
adds support for types in the process. This was also a great oppurtunity
to greatly simplify how replacement is done in the symbol table.

Fixes #56355

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

[ELF] addLibrary: fix a use-after-free bug in archiveName

It manifests as an incorrect name in --print-archive-stats=.

[ELF][test] Clean up print-archive-stats.s

[RISCV] Pre-commit tests for D130146. NFC

[lldb/ClangExpressionParser] Fix compiler error due to `clang::CreateLLVMCodeGen()` API change

[CGDebugInfo] Access the current working directory from the `VFS`

...instead of calling `llvm::sys::fs::current_path()` directly.

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

[clang-tidy] Avoid extra parentheses around MemberExpr

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

Reviewed By: aaron.ballman

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

[InstCombine] Fold strtoul and strtoull and avoid PR #56293

Reviewed By: efriedma

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

[lldb] Disable TestStackFromStdModule.py

TestStackFromStdModule.py started failing due to f4fb72e6d4ce
(https://reviews.llvm.org/D128146), with a clang assertion failure:
assert(isa<InjectedClassNameType>(Decl->TypeForDecl))

[amdgpu][nfc] Separate LDS struct creation from RAUW

[Support] Workaround compiler bug in MSVC

https://developercommunity.visualstudio.com/t/Prev-Issue---with-__assume-isnan-/1597317

This was causing unittest failures on Windows for the GitHub actions
based CI we use in the release branches.

Failed Tests (2):
  LLVM-Unit :: Support/./SupportTests.exe/FormatVariadicTest.BigTest
  LLVM-Unit :: Support/./SupportTests.exe/NativeFormatTest.BoundaryTests

Reviewed By: RKSimon

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

[AggressiveInstCombine] convert sqrt libcalls with "nnan" to sqrt intrinsics

This is an alternate to D129155 that uses TTI.haveFastSqrt() to avoid a
potential miscompile for programs with reads of errno. Moving the transform
to AggressiveInstCombine provides access to TTI.

If a sqrt call has "nnan", that implies that the input argument is never
negative because sqrt of {negative number} --> NAN.
If the argument is never negative and the call can be lowered without a
libcall, then we can assume that errno accesses are unchanged after lowering,
so the call can be translated to the LLVM intrinsic (which is expected to
become inline code).

This affects codegen for targets like x86 that have sqrt instructions, but
still have to conservatively assume that a libcall may be needed to set
errno as shown in issue #52620 and issue #56383.

This patch won't solve those examples - we will need to extend this to use
CannotBeOrderedLessThanZero or similar, enhance that analysis for new
operators, and/or deal with llvm.assume too.

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

[Clang][Doc] Update the release note for clang

Add the support for `atomic compare` and `atomic compare capture` in the
release note of clang.

Reviewed By: jdoerfert

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