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>

[NFC][CLANG] Fix issue with dereference null return value found by Coverity static analyzer tool

Reported by Coverity:

  In clang::FunctionDecl::isReplaceableGlobalAllocationFunction(std::optional<unsigned int> *, bool *): Return value of function which returns null is dereferenced without checking

  if (!IsSizedDelete && !Ty.isNull() && Ty->isEnumeralType()) {
       QualType T = Ty;
       //Condition TD, taking false branch.
      while (const auto *TD = T->getAs<TypedefType>())
        T = TD->getDecl()->getUnderlyingType();
        //returned_null: getAs returns nullptr (checked 95 out of 97 times).

      //Dereference null return value (NULL_RETURNS)
      // dereference: Dereferencing a pointer that might be nullptr T->getAs() when calling getDecl.
      IdentifierInfo *II = T->getAs<EnumType>()->getDecl()->getIdentifier();
      if (II && II->isStr("__hot_cold_t"))
        Consume();
    }

This patch uses castAs instead of getAs which will assert if the type doesn't match.

Reviewed By: erichkeane

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

[BOLT] Add isParentOf and isParentOrChildOf BF checks

Add helper methods and simplify cases where we want to check if two functions
are parent-child of each other (function-fragment relationship).

Reviewed By: #bolt, rafauler

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

[BOLT][NFC] Extract DataAggregator::parseLBRSample

Reviewed By: #bolt, rafauler

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

[mlir][sparse][gpu] recognize SpMM cuSparse during sparsification

Reviewed By: Peiming

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

[mlir][sparse][gpu] derive type of cuSparse op

This no longer assumes just F64 output.

Note, however, that it will be cleaner to carry the data type in the corresponding operation (rather than tracking operands). That will also allow for mixed type cases, where operands and result type are different

This will be done in a follow revision where the result type is carried by the SpMV/SpMM op itself (and friends).

Reviewed By: Peiming

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

[mlir][sparse] Improving error-detection for `STEA::get{Pos,Crd}Type`

Reviewed By: aartbik

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

[MLIR][TOSA] add tosa erf operator

This commit adds tosa erf operator and its lowering
to math lib functions.

Reviewed By: eric-k256, jpienaar

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

ValueTracking: Add baseline tests for some assume handling

Fix broken C++ mode comment

GlobalISel: Move fconstant matching into tablegen

I don't really understand what the point of wip_match_opcode is.
It doesn't seem to have any purpose other than to list opcodes
to have all the logic in pure C++. You can't seem to  use it to
select multiple opcodes in the same way you use match.

Something is wrong with it, since the match emitter prints
"errors" if an opcode is covered by wip_match_opcode and
then appears in another pattern. For exmaple with this patch,
you see this several times in the build:

  error: Leaf constant_fold_fabs is unreachable
  note: Leaf idempotent_prop will have already matched

The combines are actually produced and the tests for them
do pass, so this seems to just be a broken warning.

[clang][AST] Propagate the value-dependent bit for VAArgExpr.

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

We never set the value-dependent bit for the VAArgExpr before this
patch, this was fine becase the dependent-type TypoExpr was always
resolved before checking the operands (see https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaExpr.cpp#L21173-L21180)

Now we have enabled the dependence by default for C, the typo expr is
not early resolved before checking rather than delayed (share the same
codepath with C++).

The fix is to propagate the value-dependent bit for VAArgExpr where it contains
a TypoExpr, so that the AST node can be handled properly.

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

[bazel] Rework zlib dependency

Switches the library to use the zlib-ng implementation since the
original implementation is warning-incompatible with recent versions of clang.

Removes the wrapper logic for zlib in the bazel build and introduces new
logic to handle `LLVM_ENABLE_ZLIB`.

Removes the `BAZEL_LLVM_ZLIB_STRATEGY` environment variable and instead
introduces a boolean `--@llvm_zlib//:llvm_enable_zlib` flag which defaults
to true.

To migrate:
    * The previous "external" strategy is the default. May be explicitly
      enabled with `--@llvm_zlib//:llvm_enable_zlib=true`. For custom zlib
      variants you can use the BUILD file at `third_party_build/zlib.BUILD`
      as reference and adjust the `@llvm_zlib` archive in the `WORKSPACE`
      directly.
    * The previous "disable" strategy may be enabled with
      `--@llvm_zlib//:llvm_enable_zlib=false`.
    * The previous "system" strategy has been removed since it breaks
      hermeticity. If you need the "system" setup, use the "external"
      strategy and override the zlib dependency.

Addresses breakages of downstream projects using upstream clang and the
previously "external" zlib strategy (D141553).

Reviewed By: MaskRay, GMNGeoffrey

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

[AMDGPU] Rewrite device ctor / dtor handling to use .init / .fini sections

Currently, AMDGPU has special handling for constructors and destructors.
We manuall emit a kernel that calls the functoins listed in the global
constructor / destructor list. This currently has two main problems. The
first is that we do not repsect the priortiy and simply call them in any
order. The second is that we redefine the symbol unconditionally which
coulid have a different definition, meaning we cannot merge any code
with a constructor post-codegen. This patch changes the handling to
instead use the standard support for travering the `.init_array` and
`.fini_array` sections the compiler creates. This allows us to emit a
single kernel with `odr` semantics, so even if we emit this multiple
times they will be merged into a single kernel.

Reviewed By: arsenm

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

[RISCV] Simplify and improve getLMULCost.

Use divideCeil for fixed vectors which avoids the need for a std::max
with 1 and should be more correct for odd sized vectors if those
occur.

Use conditional operator instead of an if/else.

[mlir][Vector] Extend xfer_read(extract)->scalar load to support multiple uses

This patch extends the vector.extract(vector.transfer_read) -> scalar
load patterns to support vector.transfer_read with multiple uses. For
now, we check that all the uses are vector.extract operations.
Supporting multiple uses is predicated under a flag.

Reviewed By: hanchung

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

Fix quadratic behavior from Operation::setAttr()  (NFC)

This API tries to ensure some backward compatibility for properties,
but doing so in multiple-layers was causing quadratic behavior.
Instead of `setAttrs()` repeatingly calling to `setAttr()` we inline
the logic and apply it locally in a single traversal.

Fixes #62800

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

[libc++] Fix issue with std::map::find in Objective-C++ with modules

This works around an issue with modules where Clang complains that
it doesn't know about `coroutine_handle<>` when trying to write very
basic code using std::map::find.

rdar://106813461

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

[clang][CodeGen] Break up TargetInfo.cpp [5/8]

Make `occupiesMoreThan` a protected member of `SwiftABIInfo`.
This method is only used by implementations of `SwiftABIInfo`.
Making it protected will allow to use it after the implementations
are moved to dedicated cpp files.

Reviewed By: efriedma

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

[clang][CodeGen] Break up TargetInfo.cpp [4/8]

Remove `getABIInfo` overrides returning references to target-specific
implementations of `ABIInfo`.
The methods may be convenient, but they are only used in one place and
prevent from `ABIInfo` implementations from being put into anonymous
namespaces in different cpp files.

Reviewed By: efriedma

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

[clang][CodeGen] Break up TargetInfo.cpp [3/8]

Don't derive from `DefaultTargetCodeGenInfo`.
This class is going to stay in `TargetInfo.cpp`, whereas its derivants
are going to be moved to separate translation units. Just derive from
the base `TargetCodeGenInfo` class instead.

Reviewed By: efriedma

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

[clang][CodeGen] Break up TargetInfo.cpp [2/8]

Move `ABIKind` enums out of `*ABIInfo` classes to break the dependency
between `getTargetCodeGenInfo` and the classes.
This will allow to move the classes to different cpp files.

Reviewed By: efriedma

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

[clang][CodeGen] Break up TargetInfo.cpp [1/8]

`CCState` is a helper class originally used by the x86 implementation
but has since been abused by other implementations.
Remove this dependency by implementing customized versions of the class
for implementations that need such functionality.

Reviewed By: efriedma, MaskRay

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

[RegScavenger] Change scavengeRegister to pick registers in allocation order

This matches what scavengeRegisterBackwards does.

This is in preparation for converting most uses of scavengeRegister to
scavengeRegisterBackwards, to reduce test case churn when that lands and
to help with bisection if anything goes wrong.

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

[mlir][arith] Fold `or(x, xor(x, 1))` -> `1`

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

[GVN] Do not combine convergent calls in GVN/NewGVN

Note that this is very conservative since it will not even combine
convergent calls that appear in the same basic block, but EarlyCSE will
handle that case.

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

[AMDGPU] Fix odd implicit operand handling in clause breaking

By inspection. Because of the strange behaviour of MI.uses(), this was
adding implicit defs to the clause *uses* set, and then wrongly
detecting a conflict between explicit defs and implicit defs.

For example it would detect a conflict on this pair of instructions:

   $vgpr0 = BUFFER_LOAD_DWORD_OFFSET $sgpr0_sgpr1_sgpr2_sgpr3, 0, 4088, 0, 0, implicit $exec, implicit-def $vgpr0_vgpr1 :: (load (s32) from %stack.1, addrspace 5)
   $vgpr1 = BUFFER_LOAD_DWORD_OFFSET $sgpr0_sgpr1_sgpr2_sgpr3, 0, 4092, 0, 0, implicit $exec, implicit-def $vgpr0_vgpr1 :: (load (s32) from %stack.1 + 4, addrspace 5)

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

[SelectionDAGBuilder] Use getPtrExtOrTrunc in place of getZExtOrTrunc. NFC

This getZExtOrTrunc seems to have been added when getPtrExtOrTrunc
was introduced. getPtrExtOrTrunc is currently equivalent to getZExtOrTrunc,
but could be changed for some target in the future.

Reviewed By: t.p.northover

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

[lldb][NFCI] Consolidate segment names in ObjectFileMachO

We have static functions for each one, we should use them where it makes
sense.

[mlir][sparse] Updating STEA documentation examples to use "lvlTypes"

Followup to D150330.

Reviewed By: aartbik

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

[mlir][sparse][gpu] add SpMM to GPU ops dialect

Reviewed By: ThomasRaoux, K-Wu

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

[test] Make mut-rec-scc.ll a bit more robust

By adding noinline

Also make the SCC have 3 functions to prevent test changes with an upcoming change.

[clang] Convert a few tests to opaque pointers

Reviewed By: nikic

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

[Hexagon] Clone dependencies instead of moving in HVC

Loads can share dependencies, and moving them for each load separately
can end up placing them in a wrong location. There was already a check
for that, but it wasn't correct.
Instead of trying to find the right location for all moved instructions
at once, create clones for each individual load.

Fix typo in comment: @{ -> @}

[Hexagon] Add more comments to HexagonVectorCombine.cpp, NFC

[libc] Fix test failing on the GPU due to undefined floating point type

We got build failures due to the handling here, explicitly set the type.

Reviewed By: sivachandra

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

[CUDA] provide wrapper functions for new NVCC builtins.

For sm_80 NVCC introduced a handful of builtins with the names that deviate from
the historic __nvvm_/__nv naming convention. Clang/LLVM does provide equivalent
builtins, but using different names. This patch maps NVCC-style builtins to
their clang counterparts.

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

[clang][RecoveryExpr] Fix a crash where a dependent type crahes on c-only code path.

A depenent type is possible in C-only path, add a proper handling when
checking the enum constant.

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

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

[AMDGPU] Remove function if FeatureWavefrontSize 32 is not supported on current GPU

Reviewed By: arsenm, b-sumner

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

[NVPTX/CUDA] added an optional src_size argument to __nvvm_cp_async*

The optional argument is needed for CUDA-11+ headers when we're compiling for
sm_80+ GPUs.

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

[AMDGPU] Fix warnings

This patch fixes warnings like:

  llvm/lib/Target/AMDGPU/SIMachineFunctionInfo.h:711: warning:
  enumerated and non-enumerated type in conditional expression

Relax test

[BOLT][CMake] Use correct output paths and passthrough necessary options

This addresses https://github.com/llvm/llvm-project/issues/62748.

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

[mlir][sparse] Support packing external data into arbitrary sparse tensor encoding.

We previously only support packing two array (values and coordinates) into COO tensors.
This patch allows packing inputs into arbitrary sparse tensor format.

It also deletes the "implicit" data canonicalization performed inside sparse compiler,
but instead requires users to canonicalize the data before passing it to the sparse compiler.

Reviewed By: aartbik

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

Fix tests failure on 75993812d5c1f269b781c34987748f2a792a579d

It follows the rules:
1. Use native path if it's already absolute
2. Use Windows back-slash if it's windows formatting.
3. Use Posix style otherwise.

[SLP][NFC] Cleanup: Remove KeyNodes set.

I don't see a good reason form having the `KeyNodes` set.
This patch removes the set.

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

Work around a modularization issue in the Python headers.

[NFC][CLANG] Fix dereference issue before null check found by Coverity static analyzer tool

Reported by Coverity static analyzer tool:

Inside "ParsePragma.cpp" file, in <unnamed>::PragmaRISCVHandler::HandlePragma(clang::Preprocessor &, clang::PragmaIntroducer, clang::Token &): All paths that lead to this null pointer comparison already dereference the pointer earlier

  PP.Lex(Tok);
  II = Tok.getIdentifierInfo();
  //deref_ptr_in_call: Dereferencing pointer II.
  StringRef IntrinsicClass = II->getName();

    //Dereference before null check (REVERSE_INULL)
    //check_after_deref: Null-checking II suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
    if (!II || !(II->isStr("vector") || II->isStr("sifive_vector"))) {
      PP.Diag(Tok.getLocation(), diag::warn_pragma_invalid_argument)
          << PP.getSpelling(Tok) << "riscv" << /*Expected=*/true
          << "'vector' or 'sifive_vector'";
      return;
  }

This patch removes redundant StringRef type 'IntrinsicClass' and checks
II->isStr("vector") || II->isStr("sifive_vector") instead to set Actions.DeclareRISCVVBuiltins or
Actions.DeclareRISCVVectorBuiltins.

Reviewed By: erichkeane

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

[VPlan] Use isUniformAfterVec in VPReplicateRecipe::execute.

I was unable to find a case where this actually changes generated code,
but it enables the bug fix in D144434. It also brings codegen in line
with the handling of stores to uniform addresses in the cost model
(D134460).

Reviewed By: Ayal

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

[1/11][IR] Permit load/store/alloca for struct of the same scalable vector type

This patch-set aims to simplify the existing RVV segment load/store
intrinsics to use a type that represents a tuple of vectors instead.

To achieve this, first we need to relax the current limitation for an
aggregate type to be a target of load/store/alloca when the aggregate
type contains homogeneous scalable vector types. Then to adjust the
prolog of an LLVM function during lowering to clang. Finally we
re-define the RVV segment load/store intrinsics to use the tuple types.

The pull request under the RVV intrinsic specification is
riscv-non-isa/rvv-intrinsic-doc#198

---

This is the 1st patch of the patch-set. This patch is originated from
D98169.

This patch allows aggregate type (StructType) that contains homogeneous
scalable vector types to be a target of load/store/alloca. The RFC of
this patch was posted in LLVM Discourse.

https://discourse.llvm.org/t/rfc-ir-permit-load-store-alloca-for-struct-of-the-same-scalable-vector-type/69527

The main changes in this patch are:

Extend `StructLayout::StructSize` from `uint64_t` to `TypeSize` to
accommodate an expression of scalable size.

Allow `StructType:isSized` to also return true for homogeneous
scalable vector types.

Let `Type::isScalableTy` return true when `Type` is `StructType`
and contains scalable vectors

Extra description is added in the LLVM Language Reference Manual on the
relaxation of this patch.

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

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

Reword diagnostic for style; NFC

Clang diagnostics do not start with a capital letter.

[PowerPC][lit] Recognize triple ppc64le.*-linux

Some Linux distributions, e.g. Red Hat, use the triple
ppc64le-redhat-linux. Add a pattern that treats ppc64le.*-linux as
powerpc64le-linux during test execution.

Reviewed By: qiucf

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

[libc++] Install GCC 13 in the docker containers

Reviewed By: ldionne, #libc, Mordante

Spies: Mordante, libcxx-commits, arichardson

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

[Clang][clang-cl] Implement `__builtin_FUNCSIG`

This patch implements __builtin_FUNCSIG intrinsic which returns the same string as __FUNCSIG__.

Fixes https://github.com/llvm/llvm-project/issues/58951
Differential Revision: https://reviews.llvm.org/D150183

[flang][hlfir] Use complete form of DesignateOp for im/re array designators.

With this change, the lowering provides full slice triples for
designators like ...%array_comp%im/re, so that the codegen
does not have to figure it out for the array_comp.
Basically, ...%array_comp%im/re is lowered the same way
as ...%array_comp(:,:,...)%im/re.

Reviewed By: jeanPerier

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

[AMDGPU][AsmParser] Refine parsing of some 32-bit instruction operands.

Eliminates the need for the custom code in parseCustomOperand().

The remaining uses of NamedOperandU32 are to be addressed separately.

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

Reviewed By: dp

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