[8/11][POC][Clang][RISCV] Define tuple type variant of vloxseg2ei32 vluxseg2ei32

For the cover letter of this patch-set, please checkout D146872.

Depends on D147913.

This is the 8th patch of the patch-set.

This patch is a proof-of-concept and will be extended to full coverage
in the future. Currently, the old non-tuple indexed segment load is
not removed, and only signed integer indexed segment load of NF=2,
EEW=32 is defined here.

Reviewed By: craig.topper

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

[Bazel] Add missing tablegen.

(For MemorySlotTypeInterfaces)

Summary:

Reviewers: khasanovaa

Subscribers:

[7/11][POC][Clang][RISCV] Define tuple type variant of vssseg2e32

For the cover letter of this patch-set, please checkout D146872.

Depends on D147912.

This is the 7th patch of the patch-set.

This patch is a proof-of-concept and will be extended to full coverage
in the future. Currently, the old non-tuple strided segment store is
not removed, and only signed integer strided segment store of NF=2,
EEW=32 is defined here.

Reviewed By: craig.topper

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

[6/11][POC][Clang][RISCV] Define tuple type variant of vlsseg2e32

For the cover letter of this patch-set, please checkout D146872.

Depends on D147911.

This is the 6th patch of the patch-set.

This patch is a proof-of-concept and will be extended to full coverage
in the future. Currently, the old non-tuple strided segment load is not
removed, and only signed integer strided segment load of NF=2, EEW=32
is defined here.

Reviewed By: craig.topper

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

[5/11][POC][Clang][RISCV] Define tuple type variant of vlseg2e32ff

For the cover letter of this patch-set, please checkout D146872.

Depends on D147774.

This is the 5th patch of the patch-set.

This patch is a proof-of-concept and will be extended to full coverage
in the future. Currently, the old non-tuple unit-stride fault-first
segment load is not removed, and only signed integer unit-stride
fault-first segment load of NF=2, EEW=32 is defined here.

Reviewed By: craig.topper

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

Revert "[Flang][OpenMP][MLIR] Add declare target attribute set and interface for the OpenMP dialect"

This reverts commit 95b0b867b0d19919133693b8e75b170fd25a9cec.

Revert until fix found for certain failing buildbots

[AMDGPU] Simplify scavenging in indirectCopyToAGPR

This just makes it clearer that we do not want the scavenger to spill
here. NFCI.

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

[LLDB] Skip TestInterruptBacktrace.py on Arm/Linux

TestInterruptBacktrace.py started randonmly failing on Arm/Linux
buildbot since e19387e6936c. This patch marks it skipped.

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

[flang][hlfir] Lower hlfir.where when there are no conflicts

Lower hlfir.where when the scheduling analysis determined that no
temporary storage is needed.

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

[clangd] Renaming: Treat member functions like other functions

... by skipping the conflict check. The same considerations apply.

Reviewed By: hokein

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

[flang][hlfir] Enable WHERE scheduling in LowerHLFIROrderedAssignments

Nothing special is needed, other than adding the logging code for where
masks and to plug the pattern. This tests mainly adds test.

Note that some of the justifications to create temps shows some lacks of
side effect interface on operations (like hlfir.transpose), or on some
transparent llvm intrinsic calls (llvm.stacksave/restore).
I think we should as much as possible try to improve this on the ops
generate code rather than special casing it here.

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

[MLIR][OpenMP] Set AllocaIP correctly for constructs nested in task

Fixes #60874

Reviewed By: psoni2628, NimishMishra

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

[Flang][OpenMP][MLIR] Add declare target attribute set and interface for the OpenMP dialect

This attribute represents the OpenMP declare target directive, it marks a function
or global as declare target by being present but also contains information on
the device_type and capture clause (link or to). It being an attribute allows it to
mark existing constructs and be converted trivially on lowering from the OpenMP
dialect to MLIR using amendOperation.

An interface has been made for the declare target attribute, with several helper
methods for managing the attribute, this interface can be applied to MLIR
operations that are allowed to be marked as declare target (as an example, it
is by default applied to func.func, LLVMFunc, fir.GlobalOps and LLVMGlobalOps).

Reviewers: kiranchandramohan

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

[Clang][RISCV] Remove unused variable `IsTuple` for structure `RVVIntrinsic`

Signed-off by: eop Chen <eop.chen@sifive.com>

[libclc] Fix linking against libLLVMSupport

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

Add missing includes.

Reviewed By: khasanovaa

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

[4/11][POC][Clang][RISCV] Define tuple type variant of vsseg2e32

For the cover letter of this patch-set, please checkout D146872.

Depends on D147731.

This is the 4th patch of the patch-set.

This patch is a proof-of-concept and will be extended to full coverage
in the future. Currently, the old non-tuple unit-stride segment store is
not removed, and only signed integer unit-strided segment store of NF=2,
EEW=32 is defined here.

Reviewed By: craig.topper

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

[3/11][POC][Clang][RISCV] Add typedef of the tuple type and define tuple type variant of vlseg2e32

For the cover letter of this patch-set, please checkout D146872.

Depends on D146873.

This is the 3rd patch of the patch-set. This patch originates from
D99593.

Note: This patch is a proof-of-concept and will be extended to full
coverage in the future. Currently, the old non-tuple unit-stride
segment load is not removed, and only signed integer unit-strided
segment load of NF=2, EEW=32 is defined here.

When replacing the old intrinsics, the extra `IsTuple` parameter under
various places will be redundant and removed.

Authored-by: eop Chen <eop.chen@sifive.com>
Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com>
Reviewed By: craig.topper

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

ValueTracking: Drop rounding mode check for constrained_sqrt in CannotBeNegativeZero

The only value that can produce -0 is exactly -0, no rounding is involved. If the
denormal mode has flushed denormal inputs, a negative value could produce -0.
The constrained intrinsics do not track the denormal mode, and this is just
generally broken in the current set of FP predicates. The move to computeKnownFPClass
will address some of these issues.

[VPlan] Add missing ifdef after 96686796f606.

Fixes build with debug printing disabled.

ValueTracking: Fix broken fabs implementation for computeKnownFPClass, again

This was only half complete. We need to enable the positive fields
for any negative classes.

ValueTracking: Add some regression tests for fabs handling in computeKnownFPClass

[Bazel] Fixup for 612781918fb01a2a0985a1c4c9200f5d5d1581cc

[SLP][RISCV] Add test for folding offsets in GEP pointer chains

[mlir] Add a generic SROA implementation.

This revision introduces a generic implementation of Scalar Replacement
Of Aggregates. In contrast to the implementation in LLVM, this focuses
on the core of SROA: destructuring aggregates. By implementing
interfaces on allocators and accessors, memory allocators can be
destructured into smaller allocators, through the MemorySlot
abstraction.

This pass only works on aggregates that are accessed in a "type-safe"
way, that is within the bounds and respecting the type of a given memory
slot. The destructuring pattern and functions only peel off the first
layer of aggregates and can safely be applied repeatedly. For
convenience, the transformation is also available as a pass that will
apply the pattern repeatedly.

Depends on D149958

Reviewed By: gysit

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

[VPlan] Move live-out printing to VPLiveOut::print (NFC).

Preparation for D150398. This brings live-out printing in line with how
printing for recipes is handled.

[JITLink][RISCV] Consider relaxable call edges for PLT edges

For linker relaxation (D149526), a new edge kind (`CallRelaxable`) was
introduced. However, this new kind was not taken into account by
`PerGraphGOTAndPLTStubsBuilder_ELF_riscv`. This patch fixes this.

Reviewed By: StephenFan

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

[lldb] Fix enumeration value 'RvvInt32m1x2' not handled in switch (NFC)

/data/llvm-project/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4851:13: error: enumeration value 'RvvInt32m1x2' not handled in switch [-Werror,-Wswitch]
    switch (llvm::cast<clang::BuiltinType>(qual_type)->getKind()) {
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
ninja: build stopped: subcommand failed.

[Bazel] Fixup for 3128b3105d7a226fc26174be265da479ff619f3e

[mlir] don't hardcode PDL_Operation in TestTransformDialectExtensions

Update operations in Transform dialect extensions used for testing to
use the more generic `TransformHandleTypeInterface` type constraint
instead of hardcoding `PDL_Operation`. See
https://discourse.llvm.org/t/rfc-type-system-for-the-transform-dialect/65702
for motivation. This is particularly important as these tests are often
used as source of best practices.

Update tests to use `!transform.any_op` instead of `!pdl.operation`.

Depends On D150785

Reviewed By: nicolasvasilache

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

[mlir] NFC: use !transform.any_op in relevant tests

Update various tests using Transform dialect extensions to pervasively
use `!transform.any_op` instead of `!pdl.operation`. Tests are sometimes
used as source of knowledge for best practices and these were doing the
opposite of what is considered best practices per
https://discourse.llvm.org/t/rfc-type-system-for-the-transform-dialect/65702.

Reviewed By: nicolasvasilache

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

[Clang][RISCV] Add missing requirement in test case rvv-tuple-type.c

Signed-off by: eop Chen <eop.chen@sifive.com>

[2/11][POC][Clang][RISCV] Define RVV tuple types

For the cover letter of this patch-set, please checkout D146872.

Depends on D146872.

This is the 2nd patch of the patch-set. This patch originates from
D97264. This patch further allows local variable declaration and
function parameter passing by adjustment in clang lowering.

Test cases are provided to demonstrate the LLVM IR generated.

Note: This patch is currently only a proof-of-concept with only a
single RVV tuple type declared here, the rest will be added when
the concept of this patch-set is accepted.

Authored-by: eop Chen <eop.chen@sifive.com>
Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com>
Reviewed By: craig.topper

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

[clang][dataflow] Fix a bug in handling of `operator->` for optional checker.

Prior to this patch, `operator->` was being handled like `operator*`: It was
associating a `Value` of type `T` with the expression result (where `T` is the
template argument of the `optional<T>`). This is correct for `operator*`, which
returns a reference (of some flavor) to `T`, so that the result of the
`CXXOperatorCallExpr` is a glvalue of type `T`. However, `operator*` returns a
`T*`, so the result of the `CXXOperatorCallExpr` is a prvalue `T*`, which should
therefore be associated with `PointerValue` that in turn refers to a `T`.

I noticed this issue while working on the migration to strict handling of
value categories (see https://discourse.llvm.org/t/70086). The current behavior
also seems problematic more generally because it's plausible that the framework
may at some point introduce behavior that assumes an `Expr` of pointer type is
always associated with a `PointerValue`.

As it turns out, this patch fixes an existing FIXME in the test
`OptionalValueInitialization`.

Depends On D150657

Reviewed By: ymandel

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

[clang][dataflow] Use `Strict` accessors in SignAnalysisTest.cpp.

This patch is part of the ongoing migration to strict handling of value categories (see https://discourse.llvm.org/t/70086 for details).

Depends On D150656

Reviewed By: sammccall, ymandel, xazax.hun

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

[clang][dataflow] Use `Strict` accessors in TypeErasedDataflowAnalysis.cpp.

This patch is part of the ongoing migration to strict handling of value categories (see https://discourse.llvm.org/t/70086 for details).

Depends On D150655

Reviewed By: sammccall, ymandel, xazax.hun

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

[clang][dataflow] Use `Strict` accessors in more places in Transfer.cpp.

This patch handles the straightforward cases. Upcoming separate patches will handle the cases that are more subtle.

This patch is part of the ongoing migration to strict handling of value categories (see https://discourse.llvm.org/t/70086 for details).

Depends On D150653

Reviewed By: sammccall, ymandel, xazax.hun

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

[LICM] Reassociate & hoist add expressions

This patch allows LICM to reassociate and hoist following expressions:
```
loop:
  %sum = add nsw %iv, %C1
  %cmp = icmp <signed pred> %sum, C2
```
where `C1` and `C2` are loop invariants. The reassociated version looks like
```
preheader:
  %inv_sum = C2 - C1
...
loop:
  %cmp = icmp <signed pred> %iv, %inv_sum
```
In order to prove legality, we need both initial addition and the newly created subtraction
to happen without overflow.

Differential Revision: https://reviews.llvm.org/D149132
Reviewed By: skatkov

[mlir][tosa] Fold consecutive tosa.abs

Consecutive tosa.abs can be fold as single abs operation since the second one has no impact.

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

[AVR][NFC] Change the owner of the AVR backend

The former owner Dylan McKay (https://reviews.llvm.org/p/dylanmckay/)
has agreed to pass the responsibility to
Ben Shi (https://reviews.llvm.org/p/benshi001/). Please refer to
https://discourse.llvm.org/t/apply-for-the-ownership-of-the-avr-backend/70624

Reviewed By: MaskRay, lattner

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

[X86] Don't crash on instruction prefetch intrinsics without PREFETCHI support.

Instead of failing to select during isel, drop the intrinsic in
lowering.

Fixes PR62839.

Reviewed By: pengfei

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

[PowerPC] Precommit test for D151055. NFC.

Fix memoery leak in MLIR use-def list ordering test

[NFC][RISCV] Replace global def containing only one field with defvar

This simplifies some code.

Reviewed By: asb

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

[flang] Handle @PROCESS directive

Treat lines that start with @process as a comment line. The directive
is accepted and ignored.

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

[RISCV] Add missing test for ctz_32 on RV64

Apparently, both of clz and ctz should have tests for _32 version on RV64.

Reviewed By: kito-cheng

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

Fix MLIR build on powerpc

The RNG initalization relied on implicit conversion that wasn't guaranteed in
the MLIR TestUseListOrders.
Also made the RNG state a pass member, the random sequence is not not reset
for each op anymore.

Preserve use-list orders in mlir bytecode

This patch implements a mechanism to read/write use-list orders from/to the mlir bytecode format. When producing bytecode, use-list orders are appended to each value of the IR. When reading bytecode, use-lists orders are loaded in memory and used at the end of parsing to sort the existing use-list chains.

Reviewed By: mehdi_amini

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

[ExecutionEngine] Re-enable JIT tests on PowerPC.

These were previously re-enabled in d771f54107c, but had to be disabled again
in 2060a72b4d7 due to test failures.

This is a next step to landing https://reviews.llvm.org/D148192, which adds
a skeleton JITLink backend for PowerPC.

The fixes for those failures were (1) to explicitly specify IsLittleEndian =
true for the MachO YAML testcases, (2) disable some example tests for examples
that aren't supported on PowerPC yet, and (3) fixing the endianness of a
relocation read/write (for ELF R_AARCH64_TSTBR14) in RuntimeDyldELF.

[Driver] Disable -fsanitize=function for ppc64be after D148573

ELFObjectWriter.cpp may report
```
error: Cannot represent a difference across sections
```
on some ppc64be configurations, likely related to some interaction
between the obsoleted ELFv1 and MC.
Unfortunately I cannot reproduce this locally with --target=powerpc64-linux-gnu.

[ubsan][test] Unsupport function.cpp in Android non-x86 on sanitizer-x86_64-linux-android after D148573

The qemu environment cannot run an executable with a link-time shared
object built during the test?
```
Input was:
<<<<<<
            1: CANNOT LINK EXECUTABLE "/data/local/tmp/Output/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_aarch64/test/ubsan/Standalone-aarch64/TestCases/TypeCheck/Function/Output/function.cpp.tmp": library "/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_aarch64/test/ubsan/Standalone-aarch64/TestCases/TypeCheck/Function/Output/function.cpp.tmp-so.so" not found: needed by main executable
```

Reland "[Driver] Support multi /guard: options"

Fixes unexpected warning.

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

Revert "Reland "[Driver] Support multi /guard: options""

This reverts commit a4f366dcd85c440a611bbc82f1d24c2d9a735251.

Found a problem during backport it to 16.x branch.
https://github.com/llvm/llvm-project-release-prs/actions/runs/5036930270/jobs/9033427592?pr=451

The reason is `-implicit-check-not='warning'` may conflict with option
name, e.g., `-treat-scalable-fixed-error-as-warning`

Reland "[Driver] Support multi /guard: options"

Fixes unexpected warning.

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

Revert "Reland "[Driver] Support multi /guard: options""

This reverts commit a4f366dcd85c440a611bbc82f1d24c2d9a735251.

Found a problem during backport it to 16.x branch.
https://github.com/llvm/llvm-project-release-prs/actions/runs/5036930270/jobs/9033427592?pr=451

The reason is `-implicit-check-not='warning'` may conflict with option
name, e.g., `-treat-scalable-fixed-error-as-warning`

[ubsan][test] Unsupport function.cpp in Android armv7 on sanitizer-x86_64-linux-android

The emulated environment has a spurious failure that causes many other
tests to XFAIL. Unsupport it for now.

```
1: CANNOT LINK EXECUTABLE "/data/local/tmp/Output/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_arm/test/ubsan/Standalone-arm/TestCases/TypeCheck/Function/Output/function.cpp.tmp": library "/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_arm/test/ubsan/Standalone-arm/TestCases/TypeCheck/Function/Output/function.cpp.tmp-so.so" not found: needed by main executable
```

Replace `const std::string&` with StringRef in TargetRegistry APIs; NFC

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

[NFC] remove duplicated dash in release note for #62447

[X86][MC] Simplify some code in X86AsmBackend.cpp, NFCI

[Bazel] Fixup for D149515 (MCTargetDesc/*.def)

[RISCV] Disable constant hoiting for multiply by a power of 2.

[RISCV] Update pr58511.ll to not use mul by constant that can be converted to shift.

Normally a mul by a power 2 will be converted to shift by InstCombine.
Hoping this will make D127115 not affect this test so much.

I've verified the change still fails with the original DAGCombiner
bug.

Revert "[msan] Don't intercept LFS prlimit64/getrlimit64 on musl"

This reverts commit b297fd7974b282b66605547c7adb2eadbf82214f.

Reverting to investigate buildbot failures.

[gn build] Port 3f1e9468f68d

[X86][MC][bolt] Share code between encoding optimization and assembler relaxation, NFCI

PUSH[16|32|64]i[8|32] are not arithmetic instructions, so I renamed the
functions.

Reviewed By: Amir

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

[msan] Don't intercept LFS prlimit64/getrlimit64 on musl

These are aliases on musl and as of 1.2.4, aren't visible by default
(only with -D_LARGEFILE64_SOURCE), and will be removed entirely in a future
release.

This fixes a runtime failure with msan on musl-1.2.4:
```
$ echo 'int main(){}' | clang -x c - -fsanitize=memory -o /dev/null
/usr/bin/x86_64-gentoo-linux-musl-ld.bfd: /usr/lib/llvm/16/bin/../../../../lib/clang/16/lib/linux/libclang_rt.msan-x86_64.a(msan_interceptors.cpp.o): in function `__interceptor_getrlimit64':
[...]
```

Bug: https://bugs.gentoo.org/906603

Reviewed By: MaskRay

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

Fix MLIR build with shared libraries enabled

Missing dependencies in CMake which does not impact static builds.

[CMake][libc] Fix non-runtime build when other runtimes are enabled

Before this patch, when other runtimes were enabled by setting
LLVM_ENABLE_RUNTIMES and llvm libc was built as a project by setting
LLVM_ENABLE_PROJECTS, the llvm libc CMake system would delay
configuration until the runtime build which never started since libc
wasn't declared as one of the runtime builds. This patch fixes this
behavior by explicitly checking that libc is within LLVM_ENABLE_RUNTIMES
rather than just the variable being set at all.

Reviewed By: Intue

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

Add support for Lazyloading to the MLIR bytecode

IsolatedRegions are emitted in sections in order for the reader to be
able to skip over them. A new class is exposed to manage the state and
allow the readers to load these IsolatedRegions on-demand.

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

[NFC] improment release note word for #62447

[gn build] Port ed59b8a11c89

[lld-macho] Remove partially supported 32-bit ARM arch

We never really supported 32-bit ARM arch entirely, and partial support was added for
very specific features. Regardless, it fails to even link the most basic applications that at
this point, it might be better to move this arch as unsupported. Given that Apple will be
moving towards arm64 long term, I don't see any reason for anyone to invest time in
supporting this either, and for those who still need it should use apple's ld64 linker.

Fixes #62691

Reviewed By: #lld-macho, int3

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

[llvm] Reduce ComplexDeinterleavingPass.h includes

Remove the unnecessary `"llvm/IR/PatternMatch.h"` include directive from
`ComplexDeinterleavingPass.h` and move it to the corresponding source
file.

Add missing includes that were transitively included by this header to 3
other source files.

This reduces the total number of preprocessing tokens across the LLVM
source files in `lib` from (roughly) 1,964,876,961 to 1,935,091,611 - a
reduction of ~1.52%. This should result in a small improvement in
compilation time.

-fsanitize=function: use type hashes instead of RTTI objects

Currently we use RTTI objects to check type compatibility. To support non-unique
RTTI objects, commit 5745eccef54ddd3caca278d1d292a88b2281528b added a
`checkTypeInfoEquality` string matching to the runtime.
The scheme is inefficient.

```
_Z1fv:
  .long   846595819                    # jmp
  .long   .L__llvm_rtti_proxy-_Z3funv
  ...

main:
  ...
  # Load the second word (pointer to the RTTI object) and dereference it.
  movslq  4(%rsi), %rax
  movq    (%rax,%rsi), %rdx
  # Is it the desired typeinfo object?
  leaq    _ZTIFvvE(%rip), %rax
  # If not, call __ubsan_handle_function_type_mismatch_v1, which may recover if checkTypeInfoEquality allows
  cmpq    %rax, %rdx
  jne     .LBB1_2
  ...

.section        .data.rel.ro,"aw",@progbits
  .p2align        3, 0x0
.L__llvm_rtti_proxy:
  .quad   _ZTIFvvE
```

Let's replace the indirect `_ZTI` pointer with a type hash similar to
`-fsanitize=kcfi`.

```
_Z1fv:
  .long   3238382334
  .long   2772461324  # type hash

main:
  ...
  # Load the second word (callee type hash) and check whether it is expected
  cmpl    $-1522505972, -4(%rax)
  # If not, fail: call __ubsan_handle_function_type_mismatch
  jne     .LBB2_2
```

The RTTI object derives its name from `clang::MangleContext::mangleCXXRTTI`,
which uses `mangleType`. `mangleTypeName` uses `mangleType` as well. So the
type compatibility change is high-fidelity.

Since we no longer need RTTI pointers in
`__ubsan::__ubsan_handle_function_type_mismatch_v1`, let's switch it back to
version 0, the original signature before
e215996a2932ed7c472f4e94dc4345b30fd0c373 (2019).
`__ubsan::__ubsan_handle_function_type_mismatch_abort` is not
recoverable, so we can revert some changes from
e215996a2932ed7c472f4e94dc4345b30fd0c373.

Reviewed By: samitolvanen

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

[clang-repl] Enable basic multiline support.

This patch allows the users to use backslash to tell clang-repl that more input
is coming. This would help support OpenMP directives which generally require to
be in separate lines.

Revert "[llvm] Reduce ComplexDeinterleavingPass.h includes"

This reverts commit 058ca5c07106d38ad66e3ec4972a613a64e88151.

[llvm] Reduce ComplexDeinterleavingPass.h includes

Remove the unnecessary `"llvm/IR/PatternMatch.h"` include directive from
`ComplexDeinterleavingPass.h` and move it to the corresponding source
file.

Add missing includes that were transitively included by this header to 2
other source files.

This reduces the total number of preprocessing tokens across the LLVM
source files in `lib` from (roughly) 1,964,876,961 to 1,935,091,611 - a
reduction of ~1.52%. This should result in a small improvement in
compilation time.

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

[Clang] Fix parsing of `(auto(x))`.

Allow auto(x) to appear in a parenthesis
expression.

The pattern (auto( can appear as part of a declarator,
so the parser is modified to avoid the ambiguity,
in a way consistent with the proposed resolution to CWG1223.

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

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

[lldb][cmake] Allow specifying custom libcxx for tests in standalone builds

Standalone builds currently do not set the `LLDB_HAS_LIBCXX`,
`LIBCXX_LIBRARY_DIR`, `LIBCXX_GENERATED_INCLUDE_DIR`.
These are necessary for API tests with `USE_LIBCPP` to run against
a custom built libcxx. Thus on all buildbots using standalone builds
(most notably the public swift-ci), the API tests always run against
the libcxx headers in the system SDK.

This patch introduces a new cmake variable `LLDB_TEST_LIBCXX_ROOT_DIR`
that allows us to point the tests in standalone builds to a custom
libcxx directory.

Since the user can control the libcxx location we can hard error if
no such custom libcxx build exists.

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

Do not run gcount test on any *armv7l* (fixes test on llvm-clang-win-x-armv7l)

There was one buildbot (for llvm-clang-win-x-armv7l) that hadn't been
run for the initial revision [1].

  [1]: https://lab.llvm.org/buildbot#builders/60/builds/12118

Reviewed By: #libc, ldionne

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

[X86] Move encoding optimization for PUSH32i, PUSH64i to MC lowering, NFCI

[clang][NFC] Fix CWG399 test

A follow-up commit for https://reviews.llvm.org/D147920 that fixes embarrasing copy-and-paste mistake.

[X86][NFC] Correct the instruction names for PUSH16i, PUSH32i

Reviewed By: maksfb

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

[Sema] avoid merge error type

fixed: https://github.com/llvm/llvm-project/issues/62447
C don't support `DependentSizedArrayType`, use `ConstantArrayType` with nullptr as `SizeExpr`

Reviewed By: erichkeane, hokein

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

Revert "[clang-repl][CUDA] Initial interactive CUDA support for clang-repl"

This reverts commit 80e7eed6a610ab3c7289e6f9b7ec006bc7d7ae31.

[clang-repl][CUDA] Initial interactive CUDA support for clang-repl

CUDA support can be enabled in clang-repl with --cuda flag.
Device code linking is not yet supported. inline must be used with all
__device__ functions.

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

[clang] Add test for CWG399

[[https://wg21.link/p1787 | P1787]]: CWG399 is resolved by explicitly appealing to the lookup for the last component of any suitable nested-name-specifier.
Wording: Otherwise, its nested-name-specifier N shall nominate a type. If N has another nested-name-specifier S, Q is looked up as if its lookup context were that nominated by S. ([basic.lookup.qual]/6.2)

CWG399 revisits a resolution to older CWG244. Our test for CWG244 covers many examples from CWG399, and it was updated in 2020 presumably aware of P1787, so I reused CWG244 test. This approach to reusing was discussed in [[https://reviews.llvm.org/D139095 | a CWG405 patch review]].

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

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

Reland "[Driver] Support multi /guard: options"

Fixes unexpected warning.

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

[ARM] Remove unused member variable MulCandidate::ReadOnly

The last use was removed by:

  commit a33e311a3b96086248cf347222f18e14e7adcf84
  Author: Sam Parker <sam.parker@arm.com>
  Date:   Mon May 13 09:23:32 2019 +0000

[Hexagon] Remove unused declaration getModuleMatchQuality

getModuleMatchQuality was removed by:

  commit c3719c36e61f6ac28fc1e12587131bcae6581671
  Author: Daniel Dunbar <daniel@zuster.org>
  Date:   Sun Aug 2 23:37:13 2009 +0000

The Hexagon port was later added with getModuleMatchQuality by:

  commit 1213a7a57fdcb6c875b3f79103fc96d3e9d30b40
  Author: Tony Linthicum <tlinth@codeaurora.org>
  Date:   Mon Dec 12 21:14:40 2011 +0000

While we are at it, this patch removes a reference to
getModuleMatchQuality in the documentation.

[Hexagon] Remove unused declaration constToFloat

The declaration was added without a corresponding function definition
by:

  commit 167d918225ecd05a63f6b8d449c317feda741e18
  Author: Krzysztof Parzyszek <kparzysz@codeaurora.org>
  Date:   Thu Jul 28 20:01:59 2016 +0000

[Hexagon] Remove unused declaration WidenHvxFpIntConv

The declaration was added without a corresponding function definition
by:

  commit 94a71361d6ada8a0e25817fe8ebe443092677e6c
  Author: Krzysztof Parzyszek <kparzysz@quicinc.com>
  Date:   Fri Sep 2 12:04:49 2022 -0700

[Hexagon] Remove unused declaration LowerHvxSetCC

The corresponding function definition was removed by:

  commit 88f11003a091219b01f234bf9f1cea11c40f808d
  Author: Krzysztof Parzyszek <kparzysz@codeaurora.org>
  Date:   Tue Feb 6 14:24:57 2018 +0000

[BPF] Remove unused declaration PreprocessCopyToReg

The corresponding function definition was removed by:

  commit ec51851026a55e1cfc7f006f0e75f0a19acb32d3
  Author: Jiong Wang <wong.kwongyuan.tools@gmail.com>
  Date:   Wed Oct 16 15:27:59 2019 +0000

[ARM] Remove unused declaration CreateParallelPairs

The declaration was added without a corresponding function definition
by:

  commit 85ad78b1cfa3932eb658365b74f5b08c25dbfb0e
  Author: Sam Parker <sam.parker@arm.com>
  Date:   Thu Jul 11 07:47:50 2019 +0000

Revert "InstSimplify: Use isKnownNeverInfOrNaN"

This reverts commit 494dee0f7a7701a57f7c5b755b4133844d0dcbdf.
Related to the other reverts, causes test failure due to nan/inf
mismatch.

[SLP] Cleanup: Remove `tryToVectorizePair()`, most probably NFC

`tryToVectorizePair()` adds a level of indirection over `tryToVectorizeList()`.
I am not really sure why it is needed, it looks redundant.

I replaced all calls to `tryToVectorizePair()` with calls to
`tryToVectorizeList()` and I am not seeing any failures.

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

[X86] Remove patterns for IMUL with immediate 8 and optimize during MC lowering, NFCI

[lldb] Fix process pid parsing issue

This patch should fix an issue when parsing the process pid and setting
it in the scripted process.

It can happen that the `crashlog.process_id` attribute is sometimes
parsed as a string. That would cause the scripted process to pick the
default value (0).

To address that, this patch makes sure that the parsed attributed is
converted to the integer type before passing it to the scripted process.

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

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

[lldb/crashlog] Load inlined symbol into interactive crashlog

Sometimes, crash reports come with inlined symbols. These provide the
exact stacktrace from the user binary.

However, when investigating a crash, it's very likely that the images related
to the crashed thread are not available on the debugging user system or
that the versions don't match. This causes interactive crashlog to show
a degraded backtrace in lldb.

This patch aims to address that issue, by parsing the inlined symbols
from the crash report and load them into lldb's target.

This patch is a follow-up to 27f27d1, focusing on inlined symbols
loading from legacy (non-json) crash reports.

To do so, it updates the stack frame regular expression to make the
capture groups more granular, to be able to extract the symbol name, the
offset and the source location if available, while making it more
maintainable.

So now, when parsing the crash report, we build a data structure
containing all the symbol information for each stackframe. Then, after
launching the scripted process for interactive mode, we write a JSON
symbol file for each module, only containing the symbols that it contains.

Finally, we load the json symbol file into lldb, before showing the user
the process status and backtrace.

rdar://97345586

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

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>