MachineScheduler.cpp: Fixup D141707, suppress `MISchedDumpReservedCycles` conditionally.

It is used in `LLVM_ENABLE_DUMP` regardless of `NDEBUG`.

[gn build] Port 5629d492df38

Reapply "[libc++][ranges]Refactor `copy{,_backward}` and `move{,_backward}`"

This reverts commit a6e1080b87db8fbe0e1afadd96af5a3c0bd5e279.

Fix the conditions when the `memmove` optimization can be applied and refactor them out into a reusable type trait, fix and significantly expand the tests.

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

[test] Deprecated llvm::TypeSize::getFixedSize => getFixedValue

Fix some -Wconstant-conversion warnings for future Clang (D139114)

[ORC] Introduce deferred allocation-actions scheme for MachOPlatform bootstrap.

This patch modifies the MachOPlatform bootstrap process to record allocation
actions for ORC runtime platform support code in a "deferred actions" vector
rather than attaching it to the corresponding LinkGraphs up-front. The deferred
allocation-actions are run after all the platform support code has been loaded
by attaching them to a separate "bootstrap-complete" graph.

This change should allow the mach-o platform support code in the ORC runtime to
use advanced mach-o platform features (e.g. static inits, TLVs), provided that
the support code does not use these features at runtime before the bootstrap
process completes, or after the shutdown process starts. This is a nice
improvement in and of itself but is motivated by specific future plans: we
want to start recording unwind info in the mach-o platform state object*, and
the recording functions will have their own frame info that needs registering.
The deferred allocation-actions scheme allows for this.

* The plan is to add a new unwind-info-lookup path to libunwind to allow it to
  call back to the ORC runtime to find unwind sections. This will simplify the
  implementation of support for JIT'd compact-unwind info.

[mlir][async] Allow to call async.execute inside async.func

This change added support of calling async execute inside async.func.
Ex.

```
async.func @async_func_call_func() -> !async.token {
  %token = async.execute {
    %c0 = arith.constant 0 : index
    memref.store %arg0, %arg1[%c0] : memref<1xf32>
    async.yield
  }
  async.await %token : !async.token
  return
}
```

Reviewed By: ezhulenev

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

[SLP] Remove unused check label from test - NFC

Revert "[Clang][Sema] Enabled implicit conversion warning for CompoundAssignment operator."

This reverts commit 4c37671a7c946ac246b52fa44a6a649b89d6310b,
aka llvmorg-16-init-17246-g4c37671a7c94

This caused many warnings in the current llvm codebase.

[clang-format] Replace DeriveLineEnding and UseCRLF with LineEnding

Below is the mapping:
LineEnding  DeriveLineEnding UseCRLF
LF                false       false
CRLF              false       true
DeriveLF          true        false
DeriveCRLF        true        true

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

[gn build] Port fdc0bf6adcee

Revert "[LoongArch][M68k] Add 'Stack Frame Layout Analysis' to pipeline tests. NFC"

I missed that a forward fix was out when reverting
0a652c540556a118bbd9386ed3ab7fd9e60a9754.

This reverts commit 488bea797e167e6bf5ddab5f7eea78031b575ba0.

Revert "[codegen] Add StackFrameLayoutAnalysisPass"

This breaks on some AArch64 bots

This reverts commit 0a652c540556a118bbd9386ed3ab7fd9e60a9754.

[OpenMP][Docs] Remove documentation on removed option

Summary:
Removes this `CLANG_OPENMP_NVPTX_DEFAULT_ARCH` documentation as it's now
been removed.

[Clang] Remove `CLANG_OPENMP_NVPTX_DEFAULT_ARCH` CMake option.

The `CLANG_OPENMP_NVPTX_DEFAULT_ARCH` is a static build configuration to
set the default OpenMP value. This was replaced in D141708 with the use
of the `nvptx-arch` tool which lets us query this at runtime instead.
This makes the behaviour between AMD and NVIDIA be more consisten and
allows users to have a default architecture that does not rely on
whoever configured the LLVM build.

Depends on D141708

Reviewed By: tra, MaskRay

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

[OpenMP] Make `-fopenmp-target=` use the `nvptx-arch` tool

Previously, if the user did not provide an architecture when using
`-fopenmp-targets=nvptx64` we used the value from
`CLANG_OPENMP_DEFAULT_NVPTX_ARCH` which is defined at compile time. This
isn't ideal because it means that the default is set when the LLVM
compiler it built. Instead this patch uses the `nvptx-arch` tool to
query it at runtime. This matches the existing behaviour of the AMDGPU
toolchain with its `amdgpu-arch` tool.

Reviewed By: jdoerfert

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

[LoongArch][M68k] Add 'Stack Frame Layout Analysis' to pipeline tests. NFC

These targets were missed in D135488.

[CodeGen] Remove uses of Register::isPhysicalRegister/isVirtualRegister. NFC

Use isPhysical/isVirtual methods.

Reviewed By: foad

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

[NFC] Suppress warning after D139114

[InstCombine] fold pow(X,Y) / X -> pow(X, Y-1)

This is one of the patterns suggested in issue #34943.

[InstCombine] fold pow(X,Y) * X -> pow(X, Y+1) (with fast-math)

This is one of the patterns suggested in issue #34943.

[InstCombine] add more tests for pow reassociation; NFC

[SPIR-V] Fix switch lowering with common compare register

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

[mlir][gpu] Fix another windows build issue

Fixes another Windows build failure (C4715) caused by
6ca1a09f03e8e940f306bea73efa935e4ee38173.

[gn build] Port 0a652c540556

[OpenMP][libomptarget][AMDGPU] Add missing declarations to fix non amdgpu builds
Fix after commit of https://reviews.llvm.org/D139208

[clang-format] Fix a bug in DerivePointerAlignment fallback

Fixes #59953.

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

[codegen] Add StackFrameLayoutAnalysisPass

Issue #58168 describes the difficulty diagnosing stack size issues
identified by -Wframe-larger-than. For simple code, its easy to
understand the stack layout and where space is being allocated, but in
more complex programs, where code may be heavily inlined, unrolled, and
have duplicated code paths, it is no longer easy to manually inspect the
source program and understand where stack space can be attributed.

This patch implements a machine function pass that emits remarks with a
textual representation of stack slots, and also outputs any available
debug information to map source variables to those slots.

The new behavior can be used by adding `-Rpass-analysis=stack-frame-layout`
to the compiler invocation. Like other remarks the diagnostic
information can be saved to a file in a machine readable format by
adding -fsave-optimzation-record.

Fixes: #58168

Reviewed By: nickdesaulniers, thegameg

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

[mlir][vector] Disallow vector.fma over vectors of integers

This is to make `vector.fma` more consistent with the standard
definition of `fma` that is defined only for flaoting point types.

Reviewed By: dcaballe

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

[mlir][vector] Masking support for reductions in Linalg vectorizer

This patch enables vectorization of reductions in Linalg vectorizer
using the vector.mask operation. It also introduces the logic to slice
and propagate the vector mask of a masked multi-reduction to their
respective lowering operations.

Reviewed By: nicolasvasilache

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

[mlir][gpu] Fix build failure / silence windows build warnings

Fixes Windows build failure (C4715) caused by
6ca1a09f03e8e940f306bea73efa935e4ee38173.

Revert "[OpenMP][OMPIRBuilder] Move SIMD alignment calculation to LLVM Frontend"

This reverts commit ed01de67433174d3157e9d239d59dd465d52c6a5.

[OpenMP][OMPIRBuilder] Move SIMD alignment calculation to LLVM Frontend

Currently default simd alignment is specified by Clang specific TargetInfo
class. This class cannot be reused for LLVM Flang. If we move the default
alignment field into TargetMachine class then we can create TargetMachine
objects and query them to find SIMD alignment.

Scope of changes:
  1) Added information about maximal allowed SIMD alignment to TargetMachine
     classes.
  2) Removed getSimdDefaultAlign function from Clang TargetInfo class.
  3) Refactored createTargetMachine function.

Reviewed By: jsjodin

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

[flang] Fix cmake errors when building the Decimal and runtime libraries standalone

Currently, cmake gives errors that check_cxx_compiler_flag and append are
unknown when building the Decimal and runtime libraries standalone. Add
the appropriate include to resolve this.

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

[cmake] Fix path to LLVMConfig.cmake for multi-config builds

D139623 replaces CMAKE_CFG_INTDIR
with '.' for multi-config builds. However, this change has
not been reflected in mlir, flang, polly, lld, and clang.
The patch updates the path to LLVMConfig.cmake for those
projects.

Reviewed By: sebastian-ne

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

[Polly] Fix REQUIRES for nvptx-dependent tests

These have been effectively disabled ever since 'nvptx' was added to
the REQUIRES clauses, because REQUIRES does not support triple checks.
The new 'target=<triple>' is supported, so switch to that scheme.
Fix up XFAIL annotations, now that these tests are actually run.

Part of the project to eliminate special handling for triples in lit
expressions.

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

Remove brittle test introduced in D140547.

AMDGPU: Use getConstantStringInfo for printf format strings

Tolerated printf format strings that are indexed globals and fixes
asserting on non-null terminated strings.

[DAGCombiner] `visitFREEZE()`: gracefully handle node invalidation

When we freeze operands of an operation that we are trying to freeze,
doing so may invalidate the original SDValue. We should just re-fetch
it from the ISD::FREEZE node, because if we bail, we'd hopefully just
revisit the node and do that again.

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

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

[NFC][DAGCombiner] Fix typo in `visitFREEZE()`

[CodeGen] Fix build failure due to missing declaration.

The failure was reported in https://github.com/llvm/llvm-project/issues/60011

FAILED: lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachineScheduler.cpp.o
"/build/llvm-toolchain-snapshot-16~++20230113111109+aba8983c9d86/build-llvm/./bin/clang++" -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I"/build/llvm-toolchain-snapshot-16~++20230113111109+aba8983c9d86/build-llvm/tools/clang/stage2-bins/lib/CodeGen" -I"/build/llvm-toolchain-snapshot-16~++20230113111109+aba8983c9d86/llvm/lib/CodeGen" -I"/build/llvm-toolchain-snapshot-16~++20230113111109+aba8983c9d86/build-llvm/tools/clang/stage2-bins/include" -I"/build/llvm-toolchain-snapshot-16~++20230113111109+aba8983c9d86/llvm/include" -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -ffile-prefix-map=/build/llvm-toolchain-snapshot-16~++20230113111109+aba8983c9d86/build-llvm/tools/clang/stage2-bins=build-llvm/tools/clang/stage2-bins -ffile-prefix-map=/build/llvm-toolchain-snapshot-16~++20230113111109+aba8983c9d86/= -no-canonical-prefixes -O2 -DNDEBUG -g1  -fno-exceptions -std=c++17 -MD -MT lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachineScheduler.cpp.o -MF lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachineScheduler.cpp.o.d -o lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachineScheduler.cpp.o -c '/build/llvm-toolchain-snapshot-16~++20230113111109+aba8983c9d86/llvm/lib/CodeGen/MachineScheduler.cpp'
/build/llvm-toolchain-snapshot-16~++20230113111109+aba8983c9d86/llvm/lib/CodeGen/MachineScheduler.cpp:2639:7: error: use of undeclared identifier 'MISchedDumpReservedCycles'
  if (MISchedDumpReservedCycles)
      ^
1 error generated.

Fixes #60011

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

[Analysis] Use isa instead of dyn_cast to suppress an unused variable warning. NFC

[DAGCombiner][RISCV] Pre-promote (zext (abs X)) to (abs (sext X)) when X has an illegal type.

Type legalization will insert a sign extend anyway. By doing it
early we can remove the zext. ComputeNumSignBits can't spot it
after type legalization because type legalization may expand
the abs to sra+xor+sub.

If the zext result type is larger than the type to be promoted to,
we'll promote to a legal type and then zext the rest of the way.
If the legal type is larger than the destination type we can promote
and then truncate.

Reviewed By: asb

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

[X86] Update check lines that are not properly auto-generated.

It looks like some CHECK lines did not use patterns for virtual
registers and the register numbering is slightly different with
EXPENSIVE_CHECKS. Use patterns manually.

[PowerPC][NFC] Add missing P10 code enablement asm/disasm tests

Fix/add missing p10 enablement asm/dis-asm tests and remove
obsolete test files now that all p10 instruction enablement patches
have been committed.

[InstCombine] fold pow(X,Y) * pow(Z,Y) -> pow(X*Z, Y) (with fast-math)

This is one of the patterns suggested in issue #34943.

[InstCombine] add tests for pow reassociation; NFC

[NFC] [scudo] actually fix DCHECK now

[NFC] [scudo] fix mistake in DCHECK

sorry, my test build (and all the pre-merge bots) did not exercise this.

[OpenMP][libomptarget][AMDGPU] lock/unlock (pin/unpin) mechanism in libomptarget amdgpu plugin (API and implementation)
The current only way to obtain pinned memory with libomptarget is to use a custom allocator llvm_omp_target_alloc_host.
This reflects well the CUDA implementation of libomptarget, but it does not correctly expose the AMDGPU runtime API,
where any system allocated page can be locked/unlocked through a call to hsa_amd_memory_lock/unlock.
This patch enables users to allocate memory through malloc (mmap, sbreak) and then pin the related memory pages
with a libomptarget special call. It is a base support in the amdgpu libomptarget plugin to enable users to prelock
their host memory pages so that the runtime doesn't need to lock them itself for asynchronous memory transfers.

Reviewed By: jdoerfert, ye-luo

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

AMDGPU: Fix format string indexes for existing llvm.printf.fmts

The index stored to the buffer is just an index into this named
metadata. It would more robust to produce a private constant table,
and use a constant expression to index into it.

Revert "[clang-scan-deps] Migrate to OptTable"

This reverts commit 0c60ec699fc1ccca2e444ceb041cad9b1dca3a64.

[clang-scan-deps] Migrate to OptTable

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

[SimplifyCFG] Reapply: when eliminating `unreachable` landing pads, mark `call`s as `nounwind`

This time the change is in it's least intrusive form since only the return
type in prototype for `removeUnwindEdge()` is changed, since only a single
specific caller need that knowledge.

We really can't recover that knowledge, and `nounwind` knowledge,
(and not just a lack of the unwind edge, aka `call` instead of `invoke`),
is e.g. part of the reasoning in e.g. `mayHaveSideEffects()`.

Note that this is call-site-specific knowledge,
just because some callsite had an `unreachable`
unwind edge, does not mean that all will.

[mlir][gpu] Migrate hard-coded address space integers to an enum attribute (gpu::AddressSpaceAttr)

This is a purely mechanical change that introduces an enum attribute in the GPU
dialect to represent the various memref memory spaces as opposed to the
hard-coded integer attributes that are currently used.

The following steps were taken to make the transition across the codebase:

1. Introduce a pass "gpu-lower-memory-space-attributes":

The pass updates all memref types that have a memory space attribute that is a
`gpu::AddressSpaceAttr`. These attributes are changed to `IntegerAttr`'s using a
mapping that is given by the caller. This pass is based on the
"map-memref-spirv-storage-class" pass and the common functions can probably
be refactored into a set of utilities under the MemRef dialect.

2. Update the verifiers of GPU/NVGPU dialect operations.

If a verifier currently checks the address space of an operand using
e.g.`getWorkspaceAddressSpace`, then it can continue to do so. However, the
checks are changed to only fail if the memory space is either missing or a wrong
value of type `gpu::AddressSpaceAttr`. Otherwise, it just assumes the address
space is correct because it was specifically lowered to something other than a
`gpu::AddressSpaceAttr`.

3. Update existing gpu-to-llvm conversion infrastructure.

In the existing gpu-to-X passes, we add a full conversion equivalent to
`gpu-lower-memory-space-attributes` just before doing the conversion to the
LLVMDialect. This is done because currently both the gpu-to-llvm passes
(rocdl,nvvm) run gpu-to-gpu rewrites within the pass, which introduce
`AddressSpaceAttr` memory space annotations. Therefore, I inserted the
memory space conversion between the gpu-to-gpu rewrites and the LLVM
conversion.

For more context see the below discourse discussion:
https://discourse.llvm.org/t/gpu-workgroup-shared-memory-address-space-is-hard-coded/

Reviewed By: ftynse

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

[Sanitizer] Clean up SANITIZER_CAN_USE_ALLOCATOR64 logic

Update: A change to this code recently broke our bots after this change enabled the 64 bit allocator for defined(aarch64): https://reviews.llvm.org/D137136

We added logic initially to get our test passing, but want to further clean up this code to enable MacOS to use allocator64 and increase readability and clarity of the logic.

rdar://103647896

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

allocation_ring_buffer_size to 0 disables stack collection

Reviewed By: hctim, eugenis

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

[VPlan] Use to_vector when iterating over a temporary vector. (NFC)

AMDGPU: Some printf call edge case tests

Check printf printing printf, and printf passed to a function.

AMDGPU: Don't expand printf users if printf is defined

[thread] Fix a FIXME with std::apply. NFCI

Revert "[lldb] Add Debugger & ScriptedMetadata reference to Platform::CreateInstance"

This reverts commit 2d53527e9c64c70c24e1abba74fa0a8c8b3392b1.

[libc++][doc] Updates the release notes.

This is a preparation for the upcoming LLVM 17 release.

Reviewed By: ldionne, philnik, avogelsgesang, jloser, #libc

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

[mlir][sparse] Improve ConcatenateOp rewriting for annotated all dense result.

Previously, we rely on InsertOp to add values to the result, in the same way we
add values to a sparse tensor with compressed dimensions. We now direct store
values to the values buffer.

Reviewed By: Peiming

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

[NFC] Remove Function::getParamAlignment

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

[AArch64] Add some tests for vscale being a power 2. NFC

[Clang][Sema] Enabled implicit conversion warning for CompoundAssignment operator.

This change enables implicit conversion warnings (like Wshorten-64-to-32) for compound assignment operator with integral operands.

rdar://10466193

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

[libunwind] Fixed an upcoming clang -Wsign-conversion warning

Fixing an upcoming clang warning (from https://reviews.llvm.org/D139114) in libunwind.

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

[mlir][spirv] Fix crash in spirv-lower-abi-attributes

... when the are no SPIR-V env attributes.

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

Reviewed By: antiagainst

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

[mlir][vector] Support multiple result types in vector.mask

The verifier already had support for multiple result types, but the op definition assumed a single, optional result.

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

[Driver][RISCV] Adjust the priority between -mcpu, -mtune and -march

RISC-V supports `-march`, `-mtune`, and `-mcpu`: `-march` provides the
architecture extension information, `-mtune` provide the pipeline model, and
`-mcpu` provides both.

What's the priority among those options for now(w/o this patch)?

Pipeline model:
- Take from `-mtune` if present.
- Take from `-mcpu` if present
- Use the default pipeline model: `generic-rv32` or `generic-rv64`
Architecture extension has quite complicated behavior now:
- Take union from `-march` and `-mcpu` if both are present.
- Take from `-march` if present.
- Take from `-mcpu` if present.
- Implied from `-mabi` if present.
- Use the default architecture depending on the target triple

We treat `-mcpu`/`-mtune` and `-mcpu`/`-march` differently, and it's
kind of counterintuitive: -march is explicitly specified but ignored.

This patch adjusts the priority between `-mcpu`/`-march`, letting it use
architecture extension information from `-march` if it's present.

So the priority of architecture extension information becomes:
- Take from `-march` if present.
- Take from `-mcpu` if present.
- Implied from `-mabi` if present.
- Use the default architecture depending on the target triple

And this also match what we implement in RISC-V GCC too.

Reviewed By: craig.topper, MaskRay

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

[mlir][vector] Add scalable vectors support to OuterProductOp

This will probably be the first in a series of patches that tries to
enable code generation for ARM SME (extension of SVE).

Since SME's core operation is the outer product instruction, I figured
that it would probably be a good idea to enable the outer product
operation to properly accept and generate scalable vectors.

Reviewed By: dcaballe

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

Move definitions to prevent incomplete types.

C++20 is more strict when erroring out due to incomplete types.
Thus the code required some restructoring so that it complies in C++20.

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

Add default constructurs to `filter_iterator_impl` and `filter_iterator_impl`.

Bases of `reverse_iterator` must be default-constructible. This is enforced when using `libstdc++-12` plus C++20.

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

[mlir][bufferization][NFC] Make getEnclosingRepetitiveRegion public

These functions are generally useful and not specific to One-Shot Analysis. Move them to `BufferizableOpInterface.h` and make them public.

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

[InstCombine] improve description of fold and add TODO; NFC

D58633

[MachineCombiner] Lift same-bb restriction for reassociable ops.

This patch relaxes the restriction that both reassociate operands must
be in the same block as the root instruction.

The comment indicates that the reason for this restriction was that the
operands not in the same block won't have a depth in the trace.

I believe this is outdated; if the operand is in a different block, it
must dominate the current block (otherwise it would need to be phi),
which in turn means the operand's block must be included in the current
rance, and depths must be available.

There's a test case (no_reassociate_different_block) added in
70520e2f1c5fc4 which shows that we have accurate depths for operands
defined in other blocks.

This allows reassociation of code that computes the final reduction
value after vectorization, among other things.

Reviewed By: dmgreen

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

[HashBuilder] Simplify with C++17. NFCI

[include-cleaner] Remove a stale FIXME.

This FIXME was addressed in 0e545816a9e582af29ea4b9441fea8ed376cf52a.

[AArch64] Update 2 RME MEC instruction encodings

The encodings of these 2 RME MEC instructions are
incorrect and need swapping:

- DC CIPAE
- DC CIGDPAE

The correct encoding is:

Operation       op0     op1     CRn     CRm     op2
DC CIPAE, Xt    0b01    0b100   0b0111  0b1110  0b000
DC CIGDPAE, Xt  0b01    0b100   0b0111  0b1110  0b111

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

[AArch64] Add extra tests for sinking to umull/smull. NFC

[lld][Mach-O] Fix build with Mach-O due to missing library

Summary:
The build was failing due to an undefined symbol. This is because this
function is defined in the `BitWriter` component but was not linked.

[ARM] Accept two-register form of vnmul

The previous vnmul only accepts three registers. It should accept either
two or three registers as vmul does.

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

[analyzer] Fix a FIXME. NFCI

[MLIR] Fold outer dims permutation to pack when propagating

Instead of folding the transpose into the linalg.generic keep the
transposition in the packing operation, effectively making the
linalg.generic transparent to the propagation. Additionally, if the init
operand of the generic has users pack the init and pass it as the
operand to the generic.

Reviewed By: hanchung

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

[LVI] Check for non-speculatable instructions

When constraining an operand based on a condition at a (potentially
transitive) use site, make sure we don't skip over non-speculatable
instructions. While the result is only used under the condition,
the non-speculatable instruction may have a side-effect or UB.

Demonstrating this issue requires raising the limit on the walk,
so do that.

Deprecate DataLayout::getPrefTypeAlignment

[lldb][NFC] Remove dependency on DataLayout::getPrefTypeAlignment

[mlir][NFC] Remove dependency on DataLayout::getPrefTypeAlignment

[clang][NFC] Remove dependency on DataLayout::getPrefTypeAlignment

[CVP] Add additional tests for use-site conditions (NFC)

For longer chains, we need to consider non-speculatable instructions.

[compiler-rt] fix typo in #95507c82

Revert "Workaround an assertion failure during module build"

This reverts commit e77e14ecf17bba5f9e2ef43d8c3dbc9c86685287.

According to @rsmith on https://reviews.llvm.org/D131858, he believes
the reason for this workaround in the firstplace has been fixed.
Reverting the workaround to hopefully confirm that is the case.

[CVP] Handle use-site conditions in urem folds

[CVP] Add additional tests for use-site conditions (NFC)

[compiler-rt] Fix XFAIL conditions after converting to 'target=...'

Fixes #60002.

[IPSCCP] Enable specialization of functions.

Re-enable the optimization after having fixed the compilation error
found in SPEC/CINT2017rate/502.gcc_r when both LTO and PGO are in use
(see https://reviews.llvm.org/D141474).

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

[lld][MachO] Store test outputs in %t

[CVP] Avoid duplicate range fetch (NFC)

In preparation for switching this to use getConstantRangeAtUse().

Fix -Wlogical-op-parentheses warning inconsistency for const and constexpr values

When using the && operator within a || operator, both Clang and GCC
produce a warning for potentially confusing operator precedence.
However, Clang avoids this warning for certain patterns, such as
a && b || 0 or a || b && 1, where the operator precedence of && and ||
does not change the result.

However, this behavior appears inconsistent when using the const or
constexpr qualifiers. For example:

bool t = true;
bool tt = true || false && t; // Warning: '&&' within '||'
const bool t = true;
bool tt = true || false && t; // No warning
const bool t = false;
bool tt = true || false && t; // Warning: '&&' within '||'

The second example does not produce a warning because
true || false && t matches the a || b && 1 pattern, while the third one
does not match any of them.

This behavior can lead to the lack of warnings for complicated
constexpr expressions. Clang should only suppress this warning when
literal values are placed in the place of t in the examples above.

This patch adds the literal-or-not check to fix the inconsistent
warnings for && within || when using const or constexpr.