AST: Create __va_list in the std namespace even in C.

This ensures that the mangled type names match between C and C++,
which is significant when using -fsanitize=cfi-icall. Ideally we
wouldn't have created this namespace at all, but it's now part of
the ABI (e.g. in mangled names), so we can't change it.

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

[hwasan] Respect llvm.asan.globals.

This enable no_sanitize C++ attribute to exclude globals from hwasan
testing, and automatically excludes other sanitizers' globals (such as
ubsan location descriptors).

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

Revert "[AMDGPU] [IndirectCalls] Don't propagate attributes to address taken functions and their callees"

This reverts commit 6a3beb1f68d6791a4cd0190f68b48510f754a00a.
Test case that triggers an infinite loop before the revert is at
the review for D103138.

Implement an scf.for range folding optimization pass.

In cases where arithmetic (addi/muli) ops are performed on an scf.for loops induction variable with a single use, we can fold those ops directly into the scf.for loop.

For example, in the following code:

```
scf.for %i = %c0 to %arg1 step %c1 {
  %0 = addi %arg2, %i : index
  %1 = muli %0, %c4 : index
  %2 = memref.load %arg0[%1] : memref<?xi32>
  %3 = muli %2, %2 : i32
  memref.store %3, %arg0[%1] : memref<?xi32>
}
```

we can lift `%0` up into the scf.for loop range, as it is the only user of %i:

```
%lb = addi %arg2, %c0 : index
%ub = addi %arg2, %i : index
scf.for %i = %lb to %ub step %c1 {
  %1 = muli %0, %c4 : index
  %2 = memref.load %arg0[%1] : memref<?xi32>
  %3 = muli %2, %2 : i32
  memref.store %3, %arg0[%1] : memref<?xi32>
}
```

Reviewed By: mehdi_amini, ftynse, Anthony

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

[LVI] Remove recursion from getValueForCondition (NFCI)

Convert getValueForCondition to a worklist model instead of using
recursion.

In pathological cases getValueForCondition recurses heavily.
Stack frames are quite expensive on x86-64, and some operating
systems (e.g. Windows) have relatively low stack size limits.
Using a worklist avoids potential failures from stack overflow.

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

[AIX] Emitting diagnostics error for profile options

Only LLVM-based instrumentation profile is supported on AIX.
And it currently must be used with full LTO.

Reviewed By: hubert.reinterpretcast

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

[Clang] Check for returns_nonnull when deciding to add allocation null checks

Non-throwing allocators currently will always get null-check code. However, if the non-throwing allocator is explicitly annotated with returns_nonnull the null check should be elided.

Testing:
ninja check-all
added test case correctly elides

Reviewed By: bruno

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

[NFC] [DwarfEHPrepare] Add additional stats for EH

Stats added:

1. NumCleanupLandingPadsUnreachable: how many cleanup landing pads were optimized as unreachable
1. NumCleanupLandingPadsRemaining: how many cleanup landing pads remain
1. NumNoUnwind: Number of functions with nounwind attribute
1. NumUnwind: Number of functions with unwind attribute

DwarfEHPrepare is always run a single time as part of `TargetPassConfig::addISelPasses()` which makes it an ideal place near the end of the pipeline to record this information.

Example output from clang built with exceptions cumulative during thinLTO backend (NumCleanupLandingPadsUnreachable was not incremented):

"dwarfehprepare.NumCleanupLandingPadsRemaining": 123660,
"dwarfehprepare.NumNoUnwind": 323836,
"dwarfehprepare.NumUnwind": 472893,

Reviewed By: wenlei

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

[LangRef] add note to warn-frame-size about ODR

As sugguested by @dblaikie in D104342.

Reviewed By: dblaikie

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

[llvm-diff] Explicitly check ConstantStructs for differences

A ConstantStruct is renamed when the LLVM context sees a new one. This
makes global variable initializers appear different when they aren't.
Instead, check the ConstantStruct for equivalence.

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

[CGP][RISCV] Teach CodeGenPrepare::optimizeSwitchInst to honor isSExtCheaperThanZExt.

This optimization pre-promotes the input and constants for a
switch instruction to a legal type so that all the generated compares
share the same extend. Since RISCV prefers sext for i32 to i64
extends, we should honor that to use sext.w instead of a pair
of shifts.

Reviewed By: jrtc27

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

[SjLj] Insert UnregisterFn before musttail call

When inserting UnregisterFn, if there is a musttail call, we must insert before the call so that we don't break the musttail call contract.

Reviewed By: wenlei

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

Revert "[SjLj] Insert UnregisterFn before musttail call"

This reverts commit f36703ada3dc18388ef5cdcbb8f39f74c27ad8e9.
Test failure: https://lab.llvm.org/buildbot#builders/104/builds/3450

mailmap: add mappings for myself

Add aliases for various alternative email addresses.

[MCA][TimelineView] Fixed a bug that was causing instructions outside of the timeline-max-cycles to still be printed.

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

[libc++abi][AIX] Enable calculating addresses with DW_EH_PE_datarel

Summary:
This patch enables calculating relative addresses with the DW_EH_PE_datarel encoding using a 'base' for AIX. After setting registers for jumping to the user code in gxx_personality_v0(), 'base' is cached in exception_header member catchTemp for use in __cxa_call_unexpected if ttypeIndex is less than 0 (exception spec).

Reviewed by: MaskRay, sfertile, compnerd, libc++abi

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

[SjLj] Insert UnregisterFn before musttail call

When inserting UnregisterFn, if there is a musttail call, we must insert before the call so that we don't break the musttail call contract.

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

Replace python3 with %python in ML inlining tests.

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

[PatternMatch] Make m_VScale compatible with opaque pointers

Use GEP source type instead of pointer element type.

[NFC][AArch64] Autogenerate assembly checklines in arm64-instruction-mix-remarks.ll

[lldb] Decouple ObjCLanguage from Symtab

We can extend/modify `GetMethodNameVariants` to suit our purposes here.
What symtab is looking for is alternate names we may want to use to
search for a specific symbol, and asking for variants of a name makes
the most sense here.

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

[NFC][compiler-rt] Remove iOS xfail for unpoison-alternate-stack

This test was originally xfailed because of a bug on iOS. This has since been fixed, so reenabling the test.

[libc] Calculate ulp error after rounding MPFR result to the result type.

Reviewed By: lntue

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

[lld/mac] Delete incorrect FIXME

"""Bitcode symbols only exist before LTO runs, and only serve the purpose of
resolving visibility so LTO can better optimize. Running LTO creates ObjFiles
from BitcodeFiles, and those ObjFiles contain regular Defined symbols (with
isec set and all) that will replace the bitcode symbols. So things should
(hopefully) work as-is :)"""

  -- https://reviews.llvm.org/rGdbbc8d8333f29cf4ad6f4793da1adf71bbfdac69#inline-6081

[flang] Tweak the conditions for the GCC 7/libstdc++ workaround

This adjusts the workaround from D104731.

The issue lies in libstdc++'s classes, not GCC itself, and manifests
itself in the same way if building e.g. with clang while using
libstdc++ headers from GCC 7 (e.g. if building with Clang on Ubuntu 18.04,
while using the system default C++ library).

Therefore, change the condition to look for the version of libstdc++
instead of the compiler.

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

[Polly] Fix test after D104732.

The SCEV analysis has been improved to identify a write access as a MustWrite.

[ScalarEvolution] Clarify implementation of getPointerBase().

getPointerBase should only be looking through Add and AddRec
expressions; other expressions either aren't pointers, or can't be
looked through.

Technically, this is a functional change. For a multiply or min/max
expression, if they have exactly one pointer operand, and that operand
is the first operand, the behavior here changes. Similarly, if an AddRec
has a pointer-type step, the behavior changes. But that shouldn't be
happening in practice, and we plan to make such expressions illegal.

[NFC][ScalarEvolution] Fix SCEVNAryExpr::getType().

SCEVNAryExpr::getType() could return the wrong type for a SCEVAddExpr.
Remove it, and add getType() methods to the relevant subclasses.

NFC because nothing uses it directly, as far as I know; this is just
future-proofing.

[IRSim] Adding basic implementation of llvm-sim.

This is a similarity visualization tool that accepts a Module and
passes it to the IRSimilarityIdentifier.  The resulting SimilarityGroups
are output in a JSON file.

Tests are found in test/tools/llvm-sim and check for the file not found,
a bad module, and that the JSON is created correctly.

Reviewers: paquette, jroelofs, MaskRay

Recommit of: 15645d044bcfe2a0f63156048b302f997a717688 to fix linking
errors and GN build system.

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

[AMDGPU] Check for pointer operand while refining LDS align

Also skips the propagation if alignment is 1.

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

[docs][GISel]Added GISel documentation link

Added the GISel docs link here - https://llvm.org/docs/CodeGenerator.html#instruction-selection-section

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

IR: Fix use-list-order round-tripping for call and invoke

Fix the use-list-order for call and invoke instructions by setting the
operands in order of their index. This matches the use-list-order
prediction. Note that the verifier precludes sharing operands in callbr
(so there was no bug to fix), but that code was updated for consistency.

Bug was found during review of https://reviews.llvm.org/D104740.

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

Reland "[AArch64] handle -Wa,-march="

This reverts commit fd11a26d368c5a909fb88548fef2cee7a6c2c931, which was
reverted by 9145a3d4ab7eb05d9fb113b5392e8961df629b88 due to a test
failure on aarch64 backend, e.g.
https://lab.llvm.org/buildbot/#/builders/43/builds/7031. This patch
fixed the test failure.

Reviewed By: DavidSpickett, nickdesaulniers

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

Move dwarfdump-invalid.test into the tools/llvm-dwarfdump directory.

[Constants] Handle addrspacecast with opaque pointer type

This is the same change as D104668, but for constant expression
addrspacecasts.

Update test after https://reviews.llvm.org/D104483

[compiler-rt][hwasan] Add InitState options to thread initialization

Similar to InitOptions in asan, we can use this optional struct for
initializing some members thread objects before they are created. On
linux, this is unused and can remain undefined. On fuchsia, this will
just be the stack bounds.

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

[llvm-tapi-diff] Wrap empty string around StringLiteral NFC

This prevents invalid implicit conversation which caused buildbot
failure.

[InstCombine] Use getFunctionType()

Avoid fetching pointer element type...

[lld/mac] Don't crash on absolute symbols in unwind info generation

Fixes a regression from d6565a2dbcbe and PR50820.

[OpaquePtr] Support invoke instruction

With call support in place, this is only a matter of relaxing a
bitcode reader assertion.

[TextAPI] add symbol name prefixes to central location, NFC

These prefixes are used for printing the symbols coming from tbd files
and they were redundant across locations

Fix flang build after D104167

[OpaquePtr] Support call instruction

Add support for call of opaque pointer, currently only possible for
indirect calls.

This requires a bit of special casing in LLParser, as calls do not
specify the callee operand type explicitly.

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

ThinLTO: Fix inline assembly references to static functions with CFI

Create an internal alias with the original name for static functions
that are renamed in promoteInternals to avoid breaking inline
assembly references to them.

This relands commit 4474958d3a97dede2caa0920f7c4a4dc7aac57d3
with a fix to a use-of-uninitialized-value error that tripped
MemorySanitizer.

Link: https://github.com/ClangBuiltLinux/linux/issues/1354
Reviewed By: nickdesaulniers, pcc

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

[OpaquePtr] Mangle intrinsics with opaque pointers arguments

Mangling intrinsics with opaque pointer arguments using "op"+{address space}.

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

clang-format llvm-dwarfdump.cpp

Improve error handling in llvm-dwarfdump.

Without this patch we're only showing a generic error message derived
from the error code to the end user.

rdar://79378794

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

[Attributor] Derive AAFunctionReachability attribute.

This attribute uses Attributor's internal 'optimistic' call graph
information to answer queries about function call reachability.

Functions can become reachable over time as new call edges are
discovered.

Reviewed By: jdoerfert

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

Revert "[MLIR][LLVM] Expose type translator from LLVM to MLIR Type"

This reverts commit 5616a79398c7f10d92daf7d6387b195e95f2ac7e.

[MLIR][LLVM] Expose type translator from LLVM to MLIR Type

This commit moves the type translator from LLVM to MLIR to a public header for use by external projects or other code

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

[gn build] Port 560170fa2de5

[libcxx][views] Add drop_view.

The first view in the libc++ ranges library 🚀

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

[ConstantFold] Allow propagation of poison for and/or i1

They were disallowed due to its bad interaction with select i1 -> and/or i1.
The transformation is now disabled by D101191, so let's revive this.

[LAA] Make getPointersDiff() API compatible with opaque pointers

Make getPointersDiff() and sortPtrAccesses() compatible with opaque
pointers by explicitly passing in the element type instead of
determining it from the pointer element type.

The SLPVectorizer result is slightly non-optimal in that unnecessary
pointer bitcasts are added.

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

[Demangle][Rust] Hide implementation details NFC

Move content of the "public" header into the implementation file.

This also renames two enumerations that were previously used through
`rust_demangle::` scope, to avoid breaking a build bot with older
version of GCC that rejects uses of enumerator through `E::A` if there
is a variable with the same name as enumeration `E` in the scope.

Reviewed By: dblaikie

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

Update Bazel BUILD files up to be9a87fe9b

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

[clang-format] Add IfMacros option

https://bugs.llvm.org/show_bug.cgi?id=49354

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

[ValueTracking] look through bitcast of vector in computeKnownBits

This borrows as much as possible from the SDAG version of the code
(originally added with D27129 and since updated with big endian support).

In IR, we can test more easily for correctness than we did in the
original patch. I'm using the simplest cases that I could find for
InstSimplify: we computeKnownBits on variable shift amounts to see if
they are zero or in range. So shuffle constant elements into a vector,
cast it, and shift it.

The motivating x86 example from https://llvm.org/PR50123 is also here.
We computeKnownBits in the caller code, but we only check if the shift
amount is in range. That could be enhanced to catch the 2nd x86 test -
if the shift amount is known too big, the result is 0.

Alive2 understands the datalayout and agrees that the tests here are
correct - example:
https://alive2.llvm.org/ce/z/KZJFMZ

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

[ARM] Limit v6m unrolling with multiple live outs

v6m cores only have a limited number of registers available. Unrolling
can mean we spend more on stack spills and reloads than we save from the
unrolling. This patch adds an extra heuristic to put a limit on the
unroll count for loops with multiple live out values, as measured from
the LCSSA phi nodes.

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

[InstCombine] Eliminate casts to optimize ctlz operation

If a ctlz operation is performed on higher datatype and then
downcasted, then this can be optimized by doing a ctlz operation
on a lower datatype and adding the difference bitsize to the result
of ctlz to provide the same output:

https://alive2.llvm.org/ce/z/8uup9M

The original problem is shown in
https://llvm.org/PR50173

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

[UpdateCCTestChecks][NFC] Permit other comments in common.py

Some parts of common.py already permit comment styles besides `;`.
Handle the remaining cases.  Specifically, a future patch will extend
update_cc_test_checks.py to call add_global_checks.

Reviewed By: jdoerfert

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

[RISCV] Add explicit copy to V0 in the masked vmsge(u).vx intrinsic handling.

This is consistent with our other masked vector instructions.
Previously we found cases where not doing this broke fast reg
alloc.

[InstCombine] convert FP min/max with negated op to fabs

This is part of improving floating-point patterns seen in:
https://llvm.org/PR39480

We don't require any FMF because the 2 potential corner cases
(-0.0 and NaN) are correctly handled without FMF:
1. -0.0 is treated as strictly less than +0.0 with
   maximum/minimum, so fabs/fneg work as expected.
2. +/- 0.0 with maxnum/minnum is indeterminate, so
   transforming to fabs/fneg is more defined.
3. The sign of a NaN may be altered by this transform,
   but that is allowed in the default FP environment.

If there are FMF, they are propagated from the min/max call to
one or both new operands which seems to agree with Alive2:
https://alive2.llvm.org/ce/z/bem_xC

[OpenMP][AMDGCN] Apply fix for isnan, isinf and isfinite for amdgcn.

This fixes issues with various return types(bool/int) and was already
in place for nvptx headers, adjusted to work for amdgcn. This does
not affect hip as the change is guarded with OPENMP_AMDGCN.
Similar to D85879.

Reviewed By: jdoerfert, JonChesterfield, yaxunl

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

[libc] add benchmarks for memcmp and bzero

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

[DAGCombine] Check reassoc flags in aggressive fsub fusion

The is from discussion in https://reviews.llvm.org/D104247#inline-993387

The contract and reassoc flags shouldn't imply each other .

All the aggressive fsub fusion reassociate operations,
we should guard them with reassoc flag check.

Reviewed By: mcberg2017

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

[OpenMP] Fix delete map type in ref count debug messages

For example, without this patch:

```
$ cat test.c
int main() {
  int x;
  #pragma omp target enter data map(alloc: x)
  #pragma omp target enter data map(alloc: x)
  #pragma omp target enter data map(alloc: x)
  #pragma omp target exit data map(delete: x)
  ;
  return 0;
}
$ clang -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda test.c
$ LIBOMPTARGET_DEBUG=1 ./a.out |& grep 'Creating\|Mapping exists\|last'
Libomptarget --> Creating new map entry with HstPtrBegin=0x00007ffddf1eaea8, TgtPtrBegin=0x00000000013bb040, Size=4, RefCount=1, Name=unknown
Libomptarget --> Mapping exists with HstPtrBegin=0x00007ffddf1eaea8, TgtPtrBegin=0x00000000013bb040, Size=4, RefCount=2 (incremented), Name=unknown
Libomptarget --> Mapping exists with HstPtrBegin=0x00007ffddf1eaea8, TgtPtrBegin=0x00000000013bb040, Size=4, RefCount=3 (incremented), Name=unknown
Libomptarget --> Mapping exists with HstPtrBegin=0x00007ffddf1eaea8, TgtPtrBegin=0x00000000013bb040, Size=4, RefCount=2 (decremented)
Libomptarget --> There are 4 bytes allocated at target address 0x00000000013bb040 - is not last
```

`RefCount` is reported as decremented to 2, but it ought to be reset
because of the `delete` map type, and `is not last` is incorrect.

This patch migrates the reset of reference counts from
`DeviceTy::deallocTgtPtr` to `DeviceTy::getTgtPtrBegin`, which then
correctly reports the reset.  Based on the `IsLast` result from
`DeviceTy::getTgtPtrBegin`, `targetDataEnd` then correctly reports `is
last` for any deletion.  `DeviceTy::deallocTgtPtr` is responsible only
for the final reference count decrement and mapping removal.

An obscure side effect of this patch is that a `delete` map type when
the reference count is infinite yields `DelEntry=IsLast=false` in
`targetDataEnd` and so no longer results in a
`DeviceTy::deallocTgtPtr` call.  Without this patch, that call is a
no-op anyway besides some unnecessary locking and mapping table
lookups.

Reviewed By: grokos

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

[OpenMP] Improve ref count debug messages

For example, without this patch:

```
$ cat test.c
int main() {
  int x;
  #pragma omp target enter data map(alloc: x)
  #pragma omp target exit data map(release: x)
  ;
  return 0;
}
$ clang -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda test.c
$ LIBOMPTARGET_DEBUG=1 ./a.out |& grep 'Creating\|Mapping exists'
Libomptarget --> Creating new map entry with HstPtrBegin=0x00007ffcace8e448, TgtPtrBegin=0x00007f12ef600000, Size=4, Name=unknown
Libomptarget --> Mapping exists with HstPtrBegin=0x00007ffcace8e448, TgtPtrBegin=0x00007f12ef600000, Size=4, updated RefCount=1
```

There are two problems in this example:

* `RefCount` is not reported when a mapping is created, but it might
  be 1 or infinite.  In this case, because it's created by `omp target
  enter data`, it's 1.  Seeing that would make later `RefCount`
  messages easier to understand.
* `RefCount` is still 1 at the `omp target exit data`, but it's
  reported as `updated`.  The reason it's still 1 is that, upon
  deletions, the reference count is generally not updated in
  `DeviceTy::getTgtPtrBegin`, where the report is produced.  Instead,
  it's zeroed later in `DeviceTy::deallocTgtPtr`, where it's actually
  removed from the mapping table.

This patch makes the following changes:

* Report the reference count when creating a mapping.
* Where an existing mapping is reported, always report a reference
  count action:
    * `update suppressed` when `UpdateRefCount=false`
    * `incremented`
    * `decremented`
    * `deferred final decrement`, which replaces the misleading
      `updated` in the above example
* Add comments to `DeviceTy::getTgtPtrBegin` to explain why it does
  not zero the reference count.  (Please advise if these comments miss
  the point.)
* For unified shared memory, don't report confusing messages like
  `RefCount=` or `RefCount= updated` given that reference counts are
  irrelevant in this case.  Instead, just report `for unified shared
  memory`.
* Use `INFO` not `DP` consistently for `Mapping exists` messages.
* Fix device table dumps to print `INF` instead of `-1` for an
  infinite reference count.

Reviewed By: jhuber6, grokos

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

[libc++] Remove ad-hoc modules tests that are now unnecessary

Since we now have modules-enabled CI, it is now redundant to have ad-hoc
tests that check arbitrary things about our modules support. Instead,
the whole test suite should pass with modules enabled, period.

This patch also removes the module cache path workaround: one would
expect that modules work properly without that workaround. If that
isn't the case and we do run into flaky test failures, we can re-enable
the workaround temporarily (but that would be very vexing and we should
fix Clang ASAP if that's the case).

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

[NFC] Update arm_function_name.ll after 4de0c400317e5a92d57f2c76545061a9e7de22f8

Handle interactions between reserved identifier and user-defined suffixes

According to https://eel.is/c++draft/over.literal

> double operator""_Bq(long double);  // OK: does not use the reserved identifier _­Bq ([lex.name])
> double operator"" _Bq(long double); // ill-formed, no diagnostic required: uses the reserved identifier _­Bq ([lex.name])

Obey that rule by keeping track of the operator literal name status wrt. leading whitespace.

Fix: https://bugs.llvm.org/show_bug.cgi?id=50644

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

[AMDGPU] Remove unused multiclass MUBUF_Real_gfx10_with_name

[NFC][ARM] Fix update_llc_test_checks for thumbv7-apple-darwin, autogenerate thumb2-ifcvt1.ll

[NFC][AArch64] Autogenerate a few more tests

[NFC][ARM] Fix update_llc_test_checks for aarch64-apple-ios/thumbv7s-apple-darwin, autogenerate a few tests

[NFC][ARM] Fix update_llc_test_checks for thumbv7-apple-ios, autogenerate switch-minsize.ll

[NFC][ARM] Fix update_llc_test_checks for armv7-apple-ios, autogenerate ifcvt5.ll/ifcvt6.ll

[ARMParallelDSP] Remove unnecessary wrapper function (NFC)

AreSequentialAccesses() forwards directly to isConsecutiveAccess()
and has an unnecessary template parameter to boot.

[lldb] Remove asserts in CommandReturnObject SetError and AppendError

I added asserts to these in https://reviews.llvm.org/D104525.
They are available (directly or otherwise) via the API so we
should not assert.

Restore the previous behaviour. If the message
is empty, we return early before printing anything.
For SetError don't assert that the error is a failure.

The remaining assert is in AppendRawError which
is not part of the API.

Reviewed By: teemperor

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

[lldb][NFC] Remove some redundant semicolons on HostInfoMacOSX

[AArch64] Add CodeGen tests for vector reduction intrinsics. NFC

Tests are added for vector reduce OR, AND and XOR.

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

[clang-format] Fix a bug that indents else-comment-if incorrectly

PR50809

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

[AIX][PowerPC] Remove error when specifying mabi=vec-default on AIX

The default Altivec ABI was implemented but the clang error for specifying
its use still remains.  Users could get around this but not specifying the
type of Altivec ABI but we need to remove the error.

Reviewed By: jsji

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

[NFCI-ish][SimplifyCFGPass] Rework and generalize `ret` block tail-merging

This changes the approach taken to tail-merge the blocks
to always create a new block instead of trying to reuse some block,
and generalizes it to support dealing not with just the `ret` in the future.

This effectively lifts the CallBr restriction, although this isn't really intentional.
That is the only non-NFC change here, i'm not sure if it's reasonable/feasible to temporarily retain it.

Other restrictions of the transform remain.

Reviewed By: rnk

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

Add support for #pragma system_header with -fms-extensions

Clang already supports the pragma prefixed by "GCC" or "clang".

MSVC has more recently added support for the pragma, but without any prefix; see
https://devblogs.microsoft.com/cppblog/broken-warnings-theory/#external-headers

Differential revision: https://reviews.llvm.org/D104770

[InstSimplify] Add more poison folding optimizations

This adds more poison folding optimizations to InstSimplify.

Since all binary operators propagate poison, these are fine.

Also, the precondition of `select cond, undef, x` -> `x` is relaxed to allow the case when `x` is undef.

Reviewed By: nikic

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

[lldb] Remove CommandReturnObject's SetError(StringRef)

Replacing existing uses with AppendError.

SetError is also part of the SBI API. This remains
but instead of calling the underlying SetError it
will call AppendError.

Reviewed By: teemperor

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

[Verifier] Fail on overrunning and invalid indices for {insert,extract} vector intrinsics

With regards to overrunning, the langref (llvm/docs/LangRef.rst)
specifies:

   (llvm.experimental.vector.insert)
   Elements ``idx`` through (``idx`` + num_elements(``subvec``) - 1)
   must be valid ``vec`` indices. If this condition cannot be determined
   statically but is false at runtime, then the result vector is
   undefined.

   (llvm.experimental.vector.extract)
   Elements ``idx`` through (``idx`` + num_elements(result_type) - 1)
   must be valid vector indices. If this condition cannot be determined
   statically but is false at runtime, then the result vector is
   undefined.

For the non-mixed cases (e.g. inserting/extracting a scalable into/from
another scalable, or inserting/extracting a fixed into/from another
fixed), it is possible to statically check whether or not the above
conditions are met. This was previously missing from the verifier, and
if the conditions were found to be false, the result of the
insertion/extraction would be replaced with an undef.

With regards to invalid indices, the langref (llvm/docs/LangRef.rst)
specifies:

    (llvm.experimental.vector.insert)
    ``idx`` represents the starting element number at which ``subvec``
    will be inserted. ``idx`` must be a constant multiple of
    ``subvec``'s known minimum vector length.

    (llvm.experimental.vector.extract)
    The ``idx`` specifies the starting element number within ``vec``
    from which a subvector is extracted. ``idx`` must be a constant
    multiple of the known-minimum vector length of the result type.

Similarly, these conditions were not previously enforced in the
verifier. In some circumstances, invalid indices were permitted
silently, and in other circumstances, an undef was spawned where a
verifier error would have been preferred.

This commit adds verifier checks to enforce the constraints above.

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

[TTI] Make assertion compatible with opaque pointers

Dropping the TODO here because it applies to all uses of this method.

[LLParser] Remove special handling for call address space

Spin-off from D104740: I don't think this special handling is needed
anymore. Calls in textual IR are annotated with addrspace(N) (which
defaults to the program address space from data layout) and specifies
the expected pointer address space of the callee. There is no need
to special-case the program address space on top of that, as it
already is the default expected address space, and we shouldn't
allow use of the program address space if the call was explicitly
annotated with some other address space.

The IsCall parameter is retained because it will be used again soon.

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

[mlir][LLVMIR] Fold ExtractValueOp coming from InsertValueOp

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

[AMDGPU] Stop using LegacyLegalizerInfo. NFCI.

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

[IR] Simplify createReplacementInstr

NFCI, although the test change shows that ConstantExpr::getAsInstruction
is better than the old implementation of createReplacementInstr because
it propagates things like the sdiv "exact" flag.

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

[mlir][linalg] Change the FillOp library call signature.

Adapt the FillOp library call signature to the updated operand order introduced in https://reviews.llvm.org/D10412. The patch reverts the special treatment of FillOp in LinalgToStandard.

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

[llvm] Update tests that got missed in adee485adf84ae8a.

[SCEV] Support signed predicates in applyLoopGuards.

This adds handling for signed predicates, similar to how unsigned
predicates are already handled.

Reviewed By: nikic

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

[SCEV] Add tests with single-cond range check generated by InstComb.

[AMDGPU] Simplify collectReachableCallees. NFCI.

Don't use SCC iterators when we're only interested in reachability.
Use df_begin/df_end inline to find reachable nodes.

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

[mlir][linalg] Adapt the FillOp builder signature.

Change the build operand order from output, value to value, output. The patch makes the argument order consistent with the pretty printed order updated by https://reviews.llvm.org/D104356.

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