Revert "[libc] Use LIBC_INCLUDE_DIR in CMake rules"

This reverts commit 046deabd93aca70b508784bdd91f62305ced81e3 since
it broke libc-aarch64-ubuntu-fullbuild-dbg.

[libc] Use LIBC_INCLUDE_DIR in CMake rules

D152592 introduced LIBC_INCLUDE_DIR for the location of the include
directory, use it in relevant CMake rules.

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

[SCEV] Add flag to control invertible check for normalization.

When normalizing a SCEV expression during expansion, there should be
no need for it to be invertible, as it will only be used for code
generation. This fixes a crash after 7f5b15ad150e.

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

[UTC] Adapt version matcher to glob CLANG_VENDOR

Both the pattern for finding the clang version metadata, and the emitted
checker, are now more robust, to handle a vendor prefix.

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

[libc] Check if the hermetic test target exists

When crt1 isn't available, which is typical on baremetal, hermetic tests
aren't created and the hermetic test target won't be available.

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

[OpenMP] Minor improvement in error msg and fixes few coverity reported issues

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

[CodeGen] Add support for Splats in ComplexDeinterleaving pass

This commit allows generating of complex number intrinsics for expressions
with constants or loops invariants, which are represented as splats.
For instance, after vectorizing loops in the following code snippets,
the ComplexDeinterleaving pass will be able to generate complex number
intrinsics:

```
complex<> x = ...;
for (int i = 0; i < N; ++i)
    c[i] = a[i] * b[i] * x;
```

or

```
for (int i = 0; i < N; ++i)
    c[i] = a[i] * b[i] * (11.0 + 3.0i);
```

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

[CMake] Add /winsysroot to lld-link when LLVM_WINSYSROOT is specified

So that the linker can find libraries in the winsysroot.

Reviewed By: hans, rnk

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

Fix compile error in UnresolvedSetTest.cpp, again

My previous fix used a gcc-style attribute, but not all compilers will accept
that. Instead use [[maybe_unused]], which is what we use elsewhere for this
kind of thing.

[libc++][Modules] Remove explicit exports from modules that `export *`

This may be a clang bug, but explicit exports interfere with `export *`, especially in local submodule visibility mode. For example, exporting `depr.stdint_h` from `cstdint` causes std::int32_t to become an "unresolved using declaration" in LSV if `cstdint` and `stdint.h` are promoted to top level modules. This was previously worked around by exporting `Darwin.C.stdint` in `depr.stdint_h`, but that only works on Apple platforms, and it stops working when `cstdint` and `stdint.h` are promoted to top level modules.

Remove all of the explicit `export` statements in modules that have `export *`.

Reviewed By: ldionne, Mordante, #libc

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

[libc++][Modules] Add missing submodules

Several headers that are included by the modular headers are missing from the module map, add those in.
The either/or implementation headers `<__algorithm/pstl_backends/cpu_backends/serial.h>`/`<__algorithm/pstl_backends/cpu_backends/thread.h>` need to be textual, as does `<__undef_macros>`.

Reviewed By: ldionne, #libc

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

[NFC] Fix indentation in addcarry.ll

Fix compile error in UnresolvedSetTest.cpp with -Wall

A stage 2 buildbot that compiles with -Wall -Werror is showing a failure because
a dummy value is unused. Use the unused attribute to suppress the warning, and
add a comment about why we have this value.

[RISCV] Add VFCVT pseudos with no mask

When emitting a vfcvt with a rounding mode, we end up generating an unnecessary
vmset because the only rounding mode pseudos have a mask operand. This patch
adds a pseudo without a mask, and marks the masked variant with the
MaskedPseudo class so the doPeepholeMergeVMV optimisation knows to remove the
redundant vmset.

Reviewed By: reames

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

[libc++][format] Implements formatting pointer.

The feature is applied as DR instead of a normal paper. MSVC STL and
libstdc++ will do the same.

Implements
- P2510R3 Formatting pointers

Depends on D153192

Reviewed By: #libc, ldionne

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

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

This updates the tests to match the actual output on Windows.
Note some tests still need more investigation.

Reviewed By: #libc, ldionne

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

[lldb][NFCI] Minor cleanup of default OptionValue::GetSubValue implementation

This does 2 things:
- Corrects a minor typo (`value subvalue` -> `valid subvalue`)
- Removes an unnecessary instance of `str().c_str()` (creating a
  temporary std::string from a StringRef just to get a valid
  null-terminated string).

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

[lldb][NFCI] Deprecate SBValue::GetOpaqueType

This method, as far as I can ascertain, is non-trivial to actually use
to work with (if not impossible). It doesn't make sense to use from
Python and you do not have access to the accompanying TypeSystem, so it
doesn't really do anything useful.

A possible follow-up is to gut the implementation and have it return `nullptr`.

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

Make python into C++

`not` is a C++ keyword, but it seems to cause trouble with MSVC

[lldb] Deprecate SBHostOS threading functionality

For some context, Raphael tried to this before: https://reviews.llvm.org/D104231

These methods are not tested at all, and in some cases, are not even fully
implemented (e.g. SBHostOS::ThreadCreated). I'm not convinced it's
possible to use these correctly from Python, and I'm not aware of any
users of these methods. It's difficult to remove these methods
wholesale, but we can start with deprecating them.

A possible follow-up to this change (which may require an RFC to get
more buy in from the community) is to gut these functions entirely. That
is, remove the implementations and replace them either with nothing or
have them dump out a message to stderr saying not to use these.

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

[X86] ComputeNumSignBitsForTargetNode - attempt to recognise PACKSSDW(PACKSSDW(X,Y),PACKSSDW(Z,W)) patterns

These are often used when we're packing vXi64 comparison results, but we don't have PACKSSQD so have to bitcast, which doesn't work well with num sign bits value tracking.

[X86] Fold BITOP(PACKSS(X,Z),PACKSS(Y,W)) --> PACKSS(BITOP(X,Y),BITOP(Z,W))

Fold allsignbits pack patterns to make better use of cheap (and commutable) logic ops

[MLIR][Linalg] Named op 'add' element-wise

This adds the first strict element-wise named op to Linalg.

The semantics here is to not allow auto-cast, broadcast semantics and to
restrict the operations only to identical types. The remaining semantics
must come in the form of surrounding operations on operands, to avoid
ambiguity.

Examples:
```
  // Cast int-to-fp
  %0 = linalg.copy ins(%in: tensor<32x32xi32>)
                   outs(%out: tensor<32x32xf32>)
  %1 = linalg.add  ins(%arg, %0: tensor<32x32xf32>, tensor<32x32xf32>)
                   outs(%0: tensor<32x32xf32>)

  // This can be lowered to
  %1 = linalg.generic {...}
            ins(%arg, %in: tensor<32x32xf32>, tensor<32x32xi32>)
            outs(%0: tensor<32x32xf32>) {
    ^bb0(%a: f32, %i: i32, %out: f32):
      %f = arith.uitofp %i : f32
      %0 = arith.addf %a, %f : f32
      linalg.yield %0 : f32
  }

  // Broadcast
  %0 = linalg.broadcast ins(%in: tensor<32xf32>)
                        init(%out: tensor<32x32xf32>)
  %1 = linalg.add  ins(%arg, %0: tensor<32x32xf32>, tensor<32x32xf32>)
                   outs(%0: tensor<32x32xf32>)

  // This can be lowered to
  #bcast_map = affine_map<(d0, d1) -> (d0)>
  %1 = linalg.generic {... #bcast_map] }
            ins(%arg, %in: tensor<32x32xf32>, tensor<32xf32>)
            outs(%0: tensor<32x32xf32>) {
    ^bb0(%a: f32, %b: f32, %out: f32):
      %0 = arith.addf %a, %b : f32
      linalg.yield %0 : f32
  }
```

Once this gets accepted, other arithmetic and maths operations will be
added accordingly, with the same semantics.

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

[flang][openacc] Fix false error when common block is in copy clause

Wrong error was reported mentioning that the common block was in
more than one data sharing clause.

Reviewed By: kiranchandramohan

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

[AST] Fix bug in UnresolvedSet::erase of last element

UnresolvedSet::erase works by popping the last element then replacing
the element to be erased with that element. When the element to be
erased is itself the last element this leads to writing past the end
of the set, causing an assertion failure.

Fix this by making erase of the last element just pop that element.

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

[InstCombine] Add old extract to worklist for DCE

To make sure it is removed in the same InstCombine iteration.

[AArch64] Use known zero bits when creating BIC

If we know bits are already 0, we will not need to clear them again with a BIC.
So we can use KnownBits to shrink the size of the constant in the creation BIC
from And, potentially undoing the known-bits folds that happen during
compilation.

BIC only has a single register operand for input and output, so has less
scheduling freedom than a AND, but usually saves the materialization of a
constant.

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

[AArch64] Additional tests for creating BIC from known bits. NFC

[Clang] Fix handling of using declarations in for loop init statements.

The type was never saved, and therefore never transformed
in dependent contexts.

Reviewed By: aaron.ballman, #clang-language-wg

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

[UTC] Generalize version regex

The suffix for the git revision may not be present (or may not be
a git revision).

[ValueTracking] Support add+icmp assumes for KnownBits

Support the canonical range check pattern for KnownBits assumptions.
This is the same as the generic ConstantRange handling, just shifted
by an offset.

Minor change to clang test

Fix clang test error cuased by commit 4a49226537abafc9b372ba8ef61d14a817a5226a. Minor change in order of globals.

[Clang] Fix a crash when trying to initialize an invalid aggregate.

We did not return an error when failing to producing
a valid expression when performing the initialization of
an aggregate initialized with a parenthesized list of expressions.

This is a regression introduced in Clang 17.

Fixes #63278

Reviewed By: aaron.ballman, #clang-language-wg

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

[include-cleaner] Add a signal to down-rank exporting headers

Currently exporter can have same relevance signals as the origin header
when name match signals don't trigger.
This patch introduces a tie braker signal to boost origin headers in
such cases, this is deliberately introduced with lower significance than
public-ness to make sure we still prefer a public-exporter instead of a
private-origin header.

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

[InstCombine] Add tests for add+icmp assumes (NFC)

[Flang][OpenMP] Add source range for a few directives

The sourcerange was missing for a few directives when
they were the first directive to appear in a program
without a program statement.

Reviewed By: DavidTruby

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

[InstCombine] Fold icmps comparing usub_sat with a constant

This patch introduces a fold for the operation "usub_sat(X, C) pred C2"
where "C" and "C2" are constants. The fold is:

usub_sat(X, C) pred C2
=> (X < C)  || ((X - C) pred C2) -> when (0 pred C2) is true
=> (X >= C) && ((X - C) pred C2) -> when (0 pred C2) is false

These expressions can generally be folded into a simpler expression. As
they can sometimes emit more than one instruction, they are limited to
cases where the "usub_sat" has only one user.

Fixes #58342.

Proofs: https://alive2.llvm.org/ce/z/ws_N2J

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

[InstCombine] Test cases for D154206

Create test cases to test the fold for the expression pattern
'usub_sat(X, C) pred C2'.

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

[OpenMP] Change clang emitTargetDataCalls to use OMPIRBuilder

This patch changes the emitTargetDataCalls function in clang to make use of the OpenMPIRBuilder::createTargetData function for Target Data directive code gen.
Reapplying commit 0d8d718171192301f2beb10bd08ce62e70281a5e after fixing libomptarget test failure related to debug info.

Depends on D146557

Reviewed By: jdoerfert

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

[Flang][OpenMP] Only access the MapType if it is specified

Fixes #63638

Reviewed By: TIFitis

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

[Kaleidoscope] Fix race condition in order-of-destruction between SectionMemoryManager and its MemoryMapper

SectionMemoryManager's default memory mapper used to be a global static
object. If the SectionMemoryManager itself is a global static
object, it might be destroyed after its memory mapper and thus couldn't
use it from the destructor.

The Kaleidoscope tutorial reproduced this situation with MSVC for a long time.
Since 47f5c54f997a59bb2c65 it's triggered with GCC as well. The solution from
this patch was proposed in the existing review https://reviews.llvm.org/D107087
before, but it didn't move forward.

Reviewed By: nikic

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

[libc++] Synchronize clock selection between chrono.cpp and filesystem_clock.cpp

Note that _FilesystemClock will now be implemented by calling gettimeofday()
on Apple platforms instead of clock_gettime(). However, since both are
equivalent, this should not change the behavior on Apple platforms.
There should be no behavior change on other platforms.

In addition to being a consistency clean up, this fixes some issues seen
by folks as reported in https://reviews.llvm.org/D154390#4471924.

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

[UTC] Fix git URL regex

The previous git URL regex only matched SSH urls, starting with 'git@'.
If the repo was cloned using a https URL it would not match.

rdar://105239218

[libc++] Reformat status tables

We use 17.0 instead of Clang 17 in our status tables pretty consistently,
but not universally. This ensures that we do it universally, for all
versions.

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

Fix bazel build after https://reviews.llvm.org/D150578.

Revert "Reland "[dataflow] Add dedicated representation of boolean formulas" and followups

These changes are OK, but they break downstream stuff that needs more time to adapt :-(

This reverts commit 71579569f4399d3cf6bc618dcd449b5388d749cc.
This reverts commit 5e4ad816bf100b0325ed45ab1cfea18deb3ab3d1.
This reverts commit 1c3ac8dfa16c42a631968aadd0396cfe7f7778e0.

[flang][hlfir] avoid useless LHS temporaries inside WHERE

The need to save LHS addresses on a stack before doing an assignment
is very limited: it is only really needed for forall and vectore
subscripted LHS where the LHS cannot be computed as a descriptor.

The previous current WHERE codegen was creating address stacks for
LHS element addresses when the LHS evaluation conflicts with the
assignment (may depend on the LHS value). This is not needed
since the computed array designator for the LHS is already "saved"
before the assignment from an SSA point of view.

This patch prevents LHS temporary stack from being created outside
of forall and vector subscripted assignments.

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

[scudo] Implement Fuchsia backend for the new MemMap API

Reviewed By: Caslyn, Chia-hungDuan

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

[dataflow] use true/false literals in formulas, rather than variables

And simplify formulas containing true/false
It's unclear to me how useful this is, it does make formulas more
conveniently self-contained now (we can usefully print them without
carrying around the "true/false" labels)

(while here, simplify !!X to X, too)

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

[UTC] Add fallback support for specific metadata, and check their defs

This prevents update_cc_tests.py from emitting hard-coded identifiers
for metadata (global variable checkers still check hard-coded
identifiers). Instead it emits regex checkers that match even if the
identifiers change. Also adds a new mode for --check-globals: instead of
simply being on or off, it now has the options 'none', 'smart' and
'all', with 'none' and 'all' corresponding to the previous modes.

The 'smart' mode only emits checks for global definitions referenced
in the IR or other metadata that itself has a definition checker
emitted, making the rule transitive. It does not emit checks for
attribute sets, since that is better checked by --check-attributes. This
mode is made the new default. To make the change in default mode
backwards compatible a version bump is introduced (to v3), and the
default remains 'none' in v1 & v2.

This will result in metadata checks being emitted more often, so filters
are added to not check absolute file paths and compiler version git
hashes.

rdar://105239218

[ValueTracking] Determine assume KnownBits using ConstantRange

For non-equality icmps, we don't do any KnownBits-specific
reasoning, and just use the known bits as a constraint on the range.
We can generalize this for all predicates by round-tripping through
ConstantRange and using makeAllowedICmpRegion().

The minor improvement in zext-or-icmp is because we assume that
a value is ult [0,1], which means it must be zero.

[mlir][llvm] add basic type consistency pattern destructuring stores

This is a common pattern produced by clang and similar.
Essentially, it coalesces stores into adjacent integer fields into a single integer store.
This violates our definition of type-consistency that the pass is supposed to enforce and also prevents SROA and mem2reg from eliminating `alloca`s.

This patch fixes that by splitting these stores into multiple stores.
It does so by simply using logical shift rights and truncating the produced value to the size of the field, optionally bitcasting before storing into the field.

The implementation is currently very simple, only working on struct types of a single depth and adjacent fields in that struct, with no padding inbetween. Future work could improve on these once required.

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

[dataflow] Replace most BoolValue subclasses with references to Formula (and AtomicBoolValue => Atom and BoolValue => Formula where appropriate)

This properly frees the Value hierarchy from managing boolean formulas.

We still distinguish AtomicBoolValue; this type is used in client code.
However we expect to convert such uses to BoolValue (where the
distinction is not needed) or Atom (where atomic identity is intended),
and then fold AtomicBoolValue into FormulaBoolValue.

We also distinguish TopBoolValue; this has distinct rules for
widen/join/equivalence, and top-ness is not represented in Formula.
It'd be nice to find a cleaner representation (e.g. the absence of a
formula), but no immediate plans.

For now, BoolValues with the same Formula are deduplicated. This doesn't
seem desirable, as Values are mutable by their creators (properties).
We can probably drop this for FormulaBoolValue immediately (not in this
patch, to isolate changes). For AtomicBoolValue we first need to update
clients to stop using value pointers for atom identity.

The data structures around flow conditions are updated:
- flow condition tokens are Atom, rather than AtomicBoolValue*
- conditions are Formula, rather than BoolValue
Most APIs were changed directly, some with many clients had a
new version added and the existing one deprecated.

The factories for BoolValues in Environment keep their existing
signatures for now (e.g. makeOr(BoolValue, BoolValue) => BoolValue)
and are not deprecated. These have very many clients and finding the
most ergonomic API & migration path still needs some thought.

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

[gn build] Port 1c3ac8dfa16c

Reland "[dataflow] Add dedicated representation of boolean formulas"

This reverts commit 7a72ce98224be76d9328e65eee472381f7c8e7fe.

Test problems were due to unspecified order of function arg evaluation.

[include-cleaner] Ignore the layering-violation errors for the standalone tool

If the source code is compilable-but-layering-violation, we still want
the tool to be functional on it (rather than bailing out).

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

[X86] Fix Store AGU/Memory ports on IceLakeServer model

The IceLakeServer model was directly copied from SkylakeServer model and we didn't do much to adjust the changes in port layout etc.

IceLake handles all store AGU on ports 7/8 (and not 2/3/7 like Skylake), store memory ops are handled on ports 4/9 (and not just port 4)

Fixes #62602

[X86] Remove unnecessary VPDPB/VPDPW overrides from AlderlakeP model

Noticed while trying to resurrect D138359 - the overrides matched the base class schedule WriteVecIMul definition

[X86] Remove unnecessary vzeroall/vzeroupper overrides from znver1/znver2 models

Noticed while trying to resurrect D138359 - the overrides matched the base class schedule WriteSystem/WriteMicrocoded definition (apart from znver2 where vzeroupper is almost free)

[yaml2obj] Add support for structured COFF section data.

Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D149439

[mlir] integration tests for transform dialect matchers

Add integration tests exercising transform dialect matchers for slightly
larger compositions of structured ops, namely reductions and matrix
multiplications with optional leading and trailing elementwise
operations.

Reviewed By: qcolombet

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

[gn build] Port 5ae7fde004cb

[RISCV][test] Add commented out f128 test for llvm.frexp.ll

This represents the crash reported in <https://github.com/llvm/llvm-project/issues/63661>

[ValueTracking] Don't handle ptrtoint with mismatches sizes

When processing assumes, we also handle assumes on ptrtoint of the
value. In canonical IR, these will have the same size as the value.
However, in non-canonical IR there may be an implicit zext or
trunc, which results in a bit width mismatch. We currently handle
this by adjusting bitwidth everywhere, but this is fragile and I'm
pretty sure that the way we do this is incorrect for some predicates,
because we effectively end up commuting an ext/trunc and an icmp.

Instead, add an m_PtrToIntSameSize() matcher that will only handle
bitwidth preserving cases. For the bitwidth-changing cases, wait
until they have been canonicalized.

The original handling for this was added purely to prevent crashes
in an earlier implementation which failed to account for this
entirely.

[clangd][c++20] Drop first template argument in code completion in some contexts.

In case of a top level context the first template argument of a concept
should be dropped. Currently the indexer doesn't support different
signatures for different contexts (for an index entry always the default
`Symbol` context is used). Thus we add a hack which checks if we are in
a top level context and have a concept and in that case removes the
first argment of the signature and snippet suffix. If there is only a
single argument, the signature and snippet suffix are completly
removed. The check for the first argument is done by simply looking for
the first comma which should be sufficient in most cases.

Additionally extend test environment to support adding artificial index
entries with signature and completion snippet suffix.

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

[AMDGPU][AsmParser][NFC] Generate printers for named-bit operands automatically.

Part of <https://github.com/llvm/llvm-project/issues/62629>.

Reviewed By: foad

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

[AMDGPU][AsmParser] Simplify the implementation of SWZ operands.

Those are implicit helper operands and therefore don't need any parsers
or printers.

Part of <https://github.com/llvm/llvm-project/issues/62629>.

Reviewed By: piotr, foad

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

[AMDGPU][AsmParser][NFC] Clean up the implementation of KImmFP operands.

addKImmFPOperands() duplicates the KImmFP-specific logic implemented in
addLiteralImmOperand() and therefore can be removed.

Part of <https://github.com/llvm/llvm-project/issues/62629>.

Reviewed By: foad

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

[RISCV][test] Add test coverage for llvm.frexp.*.* intrinsics

Reapply - the issue was that the `< %s` was missing in the RUN lines,
which didn't impact update_llc_test_checks but of course caused issues
for lit.

The test file is copied from X86 (which is also mostly shared with Arm,
PowerPC) rather than integrated into float-intrinsics.ll and
double-intrinsics.ll.

There's currently a compiler crash for the soft float cases (expect this
is the issue in <https://github.com/llvm/llvm-project/issues/63661>)
which will be a addressed with a follow-on patch posted for review.

[mlir][tosa] Constant folding for reciprocal

Add constant fold for tosa.reciprocal, which can be applied if the input is a dense constant tensor. The reciprocal is computed for every element and the result is a tensor with the same dimensions as the input tensor.

As the input tensor might require a lot of memory and the folding might double the required memory, a heuristic decides when to actually apply the folding. Currently, the operation will be replaced only if the input constant is a splat (i.e. requires little memory) or has in single user (similar to the already existing fold for constant transposes). This keeps the additionally required space low.

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

[Clang] Reset FP options before function instantiations

This is recommit of 98390ccb80569e8fbb20e6c996b4b8cff87fbec6, reverted
in 82a3969d710f5fb7a2ee4c9afadb648653923fef, because it caused
https://github.com/llvm/llvm-project/issues/63542. Although the problem
described in the issue is independent of the reverted patch, fail of
PCH/late-parsed-instantiations.cpp indeed obseved on PowerPC and is
likely to be caused by wrong serialization of `LateParsedTemplate`
objects. In this patch the serialization is fixed.

Original commit message is below.

Previously function template instantiations occurred with FP options
that were in effect at the end of translation unit. It was a problem
for late template parsing as these FP options were used as attributes of
AST nodes and may result in crash. To fix it FP options are set to the
state of the point of template definition.

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

[X86] Remove CPU_SPECIFIC* MACROs and add getCPUDispatchMangling

This refactor patch means to remove CPU_SPECIFIC* MACROs in X86TargetParser.def
and move those information into ProcInfo of X86TargetParser.cpp. Since these
two files both maintain a table with redundant info such as cpuname and its
features supported. CPU_SPECIFIC* MACROs define some different information. This
patch dealt with them in these ways when moving:
1.mangling
This is now moved to Mangling in ProcInfo and directly initialized at array of
Processors. CPUs don't support cpu_dispatch/specific are assigned '\0' as
mangling.
2.CPU alias
The alias cpu will also be initialized in array of Processors, its attributes
will be same as its alias target cpu. Same feature list, same mangling.
3.TUNE_NAME
Before my change, some cpu names support cpu_dispatch/specific are not
supported in X86.td, which means optimizer/backend doesn't recognize them. So
they use a different TUNE_NAME to generate in IR. In this patch, I added these
missing cpu support at X86.td by utilizing existing Features and XXXTunings, so
that each cpu name can directly use its own name as TUNE_NAME to be supported
by optimizer/backend.
4.Feature list
The feature list of one CPU maintained in X86TargetParser.def is not same as
the one in X86TargetParser.cpp. It only maintains part of features of one CPU
(features defined by X86_FEATURE_COMPAT). While X86TargetParser.cpp maintains
a complete one. This patch abandons the feature list maintained by CPU_SPECIFIC*
MACROs because assigning a CPU with a complete one doesn't affect the
functionality of cpu_dispatch/specific.
Except these four info, since some of CPUs supported by cpu_dispatch/specific
doesn's support clang options like -march, -mtune before, this patch also kept
this behavior still by adding another member OnlyForCPUDispatchSpecific in
ProcInfo.

Reviewed By: pengfei, RKSimon

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

Revert "[RISCV][test] Add test coverage for llvm.frexp.*.* intrinsics"

Reverting due to weird failure.

This reverts commit 4b8162fe9ccb68b5b42f683df8df42ed43bfd5e7.

[AMDGPU] Fix expensive-checks build.

Completes <https://reviews.llvm.org/D154337>.

[RISCV][test] Add test coverage for llvm.frexp.*.* intrinsics

The test file is copied from X86 (which is also mostly shared with Arm,
PowerPC) rather than integrated into float-intrinsics.ll and
double-intrinsics.ll.

There's currently a compiler crash for the soft float cases (expect this
is the issue in <https://github.com/llvm/llvm-project/issues/63661>)
which will be a addressed with a follow-on patch posted for review.

[AMDGPU][NFC] Rename SIMCCodeEmitter.cpp to match the new emitter class name.

The class was renamed in <https://reviews.llvm.org/D154337>.

Reviewed By: foad

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

[gn build] Port ee165cdb1b8b

[AMDGPU] Eliminate SIMCCodeEmitter and de-virtualise encoding methods.

Simplifies some future changes needed for
<https://github.com/llvm/llvm-project/issues/62629>.

Reviewed By: arsenm

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

[llvm][TableGen][Jupyter] Note needed restart when using an IDE

Certainly with VSCode, this makes it repopulate the kernel list.

[mlir][transform] Allow arbitrary indices to be scalable

This change lifts the limitation that only the trailing dimensions/sizes
in dynamic index lists can be scalable. It allows us to extend
`MaskedVectorizeOp` and `TileOp` from the Transform dialect so that the
following is allowed:

  %1, %loops:3 = transform.structured.tile %0 [4, [4], [4]]

This is also a follow up for https://reviews.llvm.org/D153372
that will enable the following (middle vector dimension is scalable):

  transform.structured.masked_vectorize %0 vector_sizes [2, [4], 8]

To facilate this change, the hooks for parsing and printing dynamic
index lists are updated accordingly (`printDynamicIndexList` and
`parseDynamicIndexList`, respectively). `MaskedVectorizeOp` and `TileOp`
are updated to include an array of attribute of bools that captures
whether the corresponding vector dimension/tile size, respectively, are
scalable or not.

NOTE 1: I am re-landing this after the initial version was reverted. To
fix the regression and in addition to the original patch, this revision
updates the Python bindings for the transform dialect

NOTE 2: This change is a part of a larger effort to enable scalable
vectorisation in Linalg. See this RFC for more context:
  * https://discourse.llvm.org/t/rfc-scalable-vectorisation-in-linalg/

This relands 048764f23a380fd6f8cc562a0008dcc6095fb594 with fixes.

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

[llvm][TableGen][Jupyter] Note an easily encountered error

When using VSCode it'll default to the Python kernel the first
time you open the notebook. Mention this in the readme, as the fix
is simple but only if you know what to look for.

[llvm][TableGen][Jupyter] Record current python when kernel is installed

Previously the kernel.json would always point to `python3` even if you
installed using a python from a virtualenv. This meant that tools like VSCode
would try to run the kernel against the system python and fail.

Added a note to the readme about it. I've removed the need to
add to PYTHONPTHON as well, turns out it wasn't needed.

This fixes an issue reported in https://discourse.llvm.org/t/tablegen-the-playground-ipynb-file-is-not-working-as-expected/71745.

Reviewed By: awarzynski

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

[LoopUnroll] Fold add chains during unrolling

Loop unrolling tends to produce chains of
`%x1 = add %x0, 1; %x2 = add %x1, 1; ...` with one add per unrolled
iteration. This patch simplifies these adds to `%xN = add %x0, N`
directly during unrolling, rather than waiting for InstCombine to do so.

The motivation for this is that having a single add (rather than
an add chain) on the induction variable makes it a simple recurrence,
which we specially recognize in a number of places. This allows
InstCombine to directly perform folds with that knowledge, instead
of first folding the add chains, and then doing other folds in another
InstCombine iteration.

Due to the reduced number of InstCombine iterations, this also
results in a small compile-time improvement.

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

[MLIR] Fix compiler warnings (NFC)

In `TestTensorTransforms.cpp` `replaced` is nullptr I assumed the intent
was to emit the error for the `rootOp`.

In `TransformInterfaces.cpp` there were some uninitialized variables.

In `NVGPUTransformOps.cpp` `matmulOp` was never used.

Reviewed By: ftynse

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

[IRCE] Support inverted range check's predicate

IRCE expects true edge of range check's branch comes to loop.
If it meets reverse case - invert the branch.

Reviewed By: skatkov

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

[LoopUnroll] Add test for early add folding (NFC)

Test for D153540, with adds that have different overflow flags.

[clang][Tooling] Add mapping for make_error_code

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

[libc] Initiliaze the global pointer in riscv startup code.

Reviewed By: mikhail.ramalho

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

[GVNHoist] Convert test to opaque pointers (NFC)

[Attributor] Convert test to opaque pointers (NFC)

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

[cmake] Add LLVM_UNITTEST_LINK_FLAGS option

Add an option to specify additional linker flags for unit tests only.
For example, this allows using something like
-DLLVM_UNITTEST_LINK_FLAGS="-Wl,-plugin-opt=O0" if you're doing LTO
builds, or -DLLVM_UNITTEST_LINK_FLAGS="-fno-lto" if you're using
fat LTO objects.

The build system already does this itself if the LLVM_ENABLE_LTO
flag is used, but this does not cover all possible LTO configurations.

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

[clang][Interp][NFC] Remove unnecessary else blocks

[clang][Interp][NFC] Move a declaration into an if statement

[clang][Interp][NFC] Fix a doc comment

[clang][Interp][NFC] Add Descriptor::isCompositeArray()

Unused for now, but will be used in later commits.

[analyzer][NFC] Move away from using raw-for loops inside StaticAnalyzer

I'm involved with the Static Analyzer for the most part.
I think we should embrace newer language standard features and gradually
move forward.

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

[clang][NFC] Move two declarations closer to their point of use

[mlir][linalg] Do not emit FillOp for tensor.pad with zero padding

No need to fill the buffer if no padding is added. I.e., the tensor.pad is packing only.

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

[XCOFF] Force recording a relocation for weak symbol label.

Summary: Currently, if there are multiple definitions of the same symbol declared has weak linkage, the linker may choose the wrong one when they are compiled with integrated-as. This patch fixes the issue. If the target symbol is a weak label we must not attempt to resolve the fixup directly. Emit a relocation and leave resolution of the final target address to the linker.

Reviewed By: shchenz

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

[analyzer] Differentiate lifetime extended temporaries

This patch introduces a new `CXXLifetimeExtendedObjectRegion` as a representation
of the memory for the temporary object that is lifetime extended by the reference
to which they are bound.

This separation provides an ability to detect the use of dangling pointers
(either binding or dereference) in a robust manner.
For example, the `ref` is conditionally dangling in the following example:
```
template<typename T>
T const& select(bool cond, T const& t, T const& u) { return cond ? t : u; }

int const& le = Composite{}.x;
auto&& ref = select(cond, le, 10);
```
Before the change, regardless of the value of `cond`, the `select()` call would
have returned a `temp_object` region.
With the proposed change we would produce a (non-dangling) `lifetime_extended_object`
region with lifetime bound to `le` or a `temp_object` region for the dangling case.

We believe that such separation is desired, as such lifetime extended temporaries
are closer to the variables. For example, they may have a static storage duration
(this patch removes a static temporary region, which was an abomination).
We also think that alternative approaches are not viable.

While for some cases it may be possible to determine if the region is lifetime
extended by searching the parents of the initializer expr, this quickly becomes
complex in the presence of the conditions operators like this one:
```
Composite cc;
// Ternary produces prvalue 'int' which is extended, as branches differ in value category
auto&& x = cond ? Composite{}.x : cc.x;

// Ternary produces xvalue, and extends the Composite object
auto&& y = cond ? Composite{}.x : std::move(cc).x;
```

Finally, the lifetime of the `CXXLifetimeExtendedObjectRegion` is tied to the lifetime of
the corresponding variables, however, the "liveness" (or reachability) of the extending
variable does not imply the reachability of all symbols in the region.
In conclusion `CXXLifetimeExtendedObjectRegion`, in contrast to `VarRegions`, does not
need any special handling in `SymReaper`.

RFC: https://discourse.llvm.org/t/rfc-detecting-uses-of-dangling-references/70731

Reviewed By: xazax.hun

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