ADD is an associative and commutative operation, so we can do reassociation for it.

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

Since these are much like template type aliases, where we don't
track a specialization for them and just substitute them eagerly,
we can't resugar them anyway, and there is no relevant cost in just
performing a finalizing sugared substitution.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

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

Reviewed By: aartbik

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

Makes CheckTemplateArgumentList and the template deduction functions
produce a sugared converted argument list in addition to the canonical one.

This is mostly NFC except that we hook this up to a few diagnostics in
SemaOverload.

The infrastructure here will be used in subsequent patches
where we perform a finalized sugared substitution for entities
which we do not unique per specializations on canonical arguments,
and later on will be used for template specialization resugaring.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

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

Part of issue 58604. Test should have been part of
50fe87a5

Pretty sure this was harmless since the tablegen
calling convention definitions do not use pointers.

Part of issue 58604

This reverts commit 11afbf39.

There are 10 tests still failing after follow-up fix b5d0bf9b, this should get the following bots back to green:
 - https://lab.llvm.org/buildbot/#/builders/183/builds/8194
 - https://lab.llvm.org/buildbot/#/builders/186/builds/9491
 - https://lab.llvm.org/buildbot/#/builders/214/builds/3908
 - https://lab.llvm.org/buildbot/#/builders/93/builds/11740
 - https://lab.llvm.org/buildbot/#/builders/231/builds/4200
 - https://lab.llvm.org/buildbot/#/builders/121/builds/24519
 - https://lab.llvm.org/buildbot/#/builders/230/builds/4466
 - https://lab.llvm.org/buildbot/#/builders/94/builds/11639
 - https://lab.llvm.org/buildbot/#/builders/45/builds/9325
 - https://lab.llvm.org/buildbot/#/builders/124/builds/5219
 - https://lab.llvm.org/buildbot/#/builders/67/builds/8623
 - https://lab.llvm.org/buildbot/#/builders/123/builds/13836
 - https://lab.llvm.org/buildbot/#/builders/109/builds/49355
 - https://lab.llvm.org/buildbot/#/builders/58/builds/27751
 - https://lab.llvm.org/buildbot/#/builders/117/builds/9922
 - https://lab.llvm.org/buildbot/#/builders/16/builds/37012
 - https://lab.llvm.org/buildbot/#/builders/104/builds/9490
 - https://lab.llvm.org/buildbot/#/builders/42/builds/7725
 - https://lab.llvm.org/buildbot/#/builders/196/builds/20077
 - https://lab.llvm.org/buildbot/#/builders/3/builds/15217
 - https://lab.llvm.org/buildbot/#/builders/6/builds/15251
 - https://lab.llvm.org/buildbot/#/builders/9/builds/15247
 - https://lab.llvm.org/buildbot/#/builders/36/builds/26487
 - https://lab.llvm.org/buildbot/#/builders/54/builds/2474
 - https://lab.llvm.org/buildbot/#/builders/74/builds/14536
 - https://lab.llvm.org/buildbot/#/builders/5/builds/28555

This reverts commit b5d0bf9b.

The original commit is causing 10 test failures on multiple bots, reverting to get back to green.

When collecting the possible constant arguments to
specialise a function the compiler will abandon the search
on the first argument that is for some reason unsuitable as
a specialisation constant. Thus, depending on the traversal
order of the functions and call sites, the compiler can end
up with a different set of possible constants, hence with
different set of specialisations.

With this patch, the compiler will skip unsuitable
constants, but nevertheless will continue searching for
more.

Reviewed By: ChuanqiXu

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

These tests were being tested against a version of libipt from last
year. We just updated libipt to top of tree and many errors broke
because the new version of libipt emits more events than the older one,
which is fine.

`./bin/lldb-dotest -p TestTrace` passes

Epilogue loop vectorization is a feature in the vectorize intended to avoid running fully scalar code when the vector length of the main loop turns out to be either longer than the trip count of the actual loop, or with a huge remainder.

In practice, this feature appears to not have been well tuned. I honestly don't think it should be on by default at all, but it definitely shouldn't be on for RISCV. Note that other targets have also disabled it, but they've done so via disabling interleaving - which is, well, completely unrelated - and we don't want to do that for RISCV.

In the near term, many examples I'm seeing have terrible codegen for epilogue vectorization. We are greatly increasing code size for little value at reasonable VLEN values for small types. In the long term, the cases that epilogue vectorization are intended to handle are likely better handled via tail folding on RISCV.

As an aside, I also don't really trust the correctness of epilogue vectorization. The code structure is such that otherwise straight forward changes sometimes break only epilogue vectorization. The reuse of an existing vplan without careful validation opens significant room for nasty bugs. Given how rarely the code is exercised, that is not a good combination.

As such, this patch introduces a TTI hook, and completely disables epilogue vectorization on RISCV.

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

debugserver is currently using kernel supplied macros,
arm_thread_state64_get_{pc,fp,sp,lr} which can crash on an authorization
failure when the inferior has crashed with an invalid pc value, for
instance.  debugserver needs to be resistant to crashing in this
scenario, and we're merely clearing the bits, so do it with a bit
mask operation instead.

Differential Revision: https://reviews.llvm.org/D136620
rdar://98073271
rdar://100663221

Provides an initializer for the TypedefInfo.IsUsing member. Previously
this member was uninitialized and would produce random output.

Adds the Description (code comments) to the bitcode reader/writer.
Previously the typedef/using descriptions were lost during the bitcode
round-trip. Adds a test for this.

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

ld64 emits them in address order but not in alphabetical order. This
sorting is particularly expensive for dead-stripped symbols (which don't
need to be sorted at all, unlike live symbols that need to be sorted by
address).

Timings for chromium_framework_less_dwarf (with the `-map` flag added to
the response file) on my 16-core Mac Pro:

             base           diff           difference (95% CI)
  sys_time   1.997 ± 0.038  2.004 ± 0.028  [  -0.6% ..   +1.3%]
  user_time  8.698 ± 0.085  8.167 ± 0.070  [  -6.6% ..   -5.6%]
  wall_time  7.965 ± 0.114  7.715 ± 0.347  [  -5.1% ..   -1.2%]
  samples    25             23

Reviewed By: #lld-macho, thakis

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

There is a bug in lldb-vscode that only shows stop reason ("exception") in
stopped event without showing the stop description of thrown exception. This
causes VSCode UI to only show "Paused on Exception" general message in
callstack window UI.

This patch fixes the bug so that VSCode callstack will show the detailed
exceptioni description, like "signal SIGABRT" or "EXC_BAD_ACCESS..." which
aligns with command line lldb experience.

I use C++ exception in testcase because the hardware exception description is
platform dependent and hard to verify.

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

Reviewed By: MaskRay

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

Add a flag to allow disabling the changes in
https://reviews.llvm.org/D134803.

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

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

Following up on D125729, add -mcpu-mvp to wasm-ld tests that use llc to
avoid test changes as a result of default target changes.

Small functions with size under a given threshold are not
considered for specialisaion on the presumption that they
are easy to inline. This does not apply to `noinline`
functions, though.

Reviewed By: ChuanqiXu

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

Adds a generic utility for creating anonymous aarch64 pointer blocks
(automatically adding an edge to initialize the pointer if given an
initial target).

Updates the aarch64 GOTTableManager to use the utility when building
GOT entries.

Enable sign-ext and mutable-globals in -mcpu=generic. This makes these features
enabled by default.

These features are all [finished proposals], and all major wasm engines
support them.

[finished proposals]: https://github.com/WebAssembly/proposals/blob/main/finished-proposals.md

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

Accompanying https://reviews.llvm.org/D125728, this updates LLVM
Codegen's "generic" CPU to enable the same new features.

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

test/Driver/m68k-features.cpp -> test/Driver/m68k-macros.cpp
test/Driver/m68k-fixed-register.c -> test/Driver/m68k-features.cpp

The original m68k-features.cpp should really be called m68k-macros.cpp
since it's testing built-in macro definitions rather than sub-target
features. Which are part of what m68k-fixed-register.c was previously
doing. NFC.

Add the atomic subroutine, atomic_fetch_add, to the list of
intrinsic subroutines, add its last dummy argument to a check
for coindexed-object, and update test.

Reviewed By: PeteSteinfeld

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

Recent Clang changes expose _bf16 types for SSE2-enabled host compilations and
that makes those types visible furing GPU-side compilation, where it currently
fails with Sema complaining that __bf16 is not supported.

Considering that __bf16 is a storage-only type, enabling it for NVPTX if it's
enabled on the host should pose no issues, correctness-wise.

Recent NVIDIA GPUs have introduced bf16 support, so we'll likely grow better
support for __bf16 on NVPTX going forward.

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

Also, make sure those are compatible with _LIBCPP_HAS_NO_WIDE_CHARACTERS.

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

Reviewed By: michaelrj

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

mold linker creates symbols for PLT entries and that caught BOLT by
surprise. Add the support for marked PLT entries.

Fixes: #58498

Reviewed By: yota9

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

Using the legacy PM for the optimization pipeline was deprecated in 13.0.0.
Following recent changes to remove non-core features of the legacy
PM/optimization pipeline, remove DataFlowSanitizerLegacyPass.

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

This patch adds the assembly/disassembly for the following instructions:
        SDOT: (4-way, multiple and single vector): Multi-vector signed integer dot-product by vector.
              SDOT (4-way, multiple vectors): Multi-vector signed integer dot-product.
        UDOT: (4-way, multiple and single vector): Multi-vector unsigned integer dot-product by vector.
              (4-way, multiple vectors): Multi-vector unsigned integer dot-product.
    for groups of 2 and 4 ZA registers

The reference can be found here:
                https://developer.arm.com/documentation/ddi0602/2022-09

Depends on: D135563

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

In the CoarrayChecker, add checks for the constraints C1172 and
C1173, which constrain sync-stat-list. Add these checks to
sync-all-stmt, sync-images-stmt, sync-memory-stmt, and
sync-team-stmt. Also add a check for the constraint C1174 in
sync-images-stmt. Update semantics tests for these stmts.

Reviewed By: klausler

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

This patch adds the assembly/disassembly for the following instruction:
INT:
  SDOT (2-way, multiple and single vector): Multi-vector signed integer dot-product by vector.
       (2-way, multiple vectors): Multi-vector signed integer dot-product.
  UDOT (2-way, multiple and single vector): Multi-vector unsigned integer dot-product by vector.
       (2-way, multiple vectors): Multi-vector unsigned integer dot-product.
  SUDOT (multiple and indexed vector): Multi-vector signed by unsigned integer dot-product by indexed elements.
        (multiple and single vector): Multi-vector signed by unsigned integer dot-product by vector.
  USDOT (multiple and single vector): Multi-vector unsigned by signed integer dot-product by vector.
        (multiple vectors): Multi-vector unsigned by signed integer dot-product.
FP:
  BFDOT(multiple and single vector): Multi-vector BFloat16 floating-point dot-product by vector.
        (multiple vectors): Multi-vector BFloat16 floating-point dot-product.

  FDOT (multiple and single vector): Multi-vector half-precision floating-point dot-product by vector.
       (multiple vectors): Multi-vector half-precision floating-point dot-product.
For set of 2 and 4 ZA registers

The reference can be found here:
        https://developer.arm.com/documentation/ddi0602/2022-09

Depends on:D135455

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

I'm unsure what the code does without the semicolon. On the surface it
seems like the assert below it would be considered part of the if
and thus the assert would only execute if DestReg is 0. But 0 isn't
considered a virtual register so the assert should fail.

Found by PVS Studio.
Reported https://pvs-studio.com/en/blog/posts/cpp/1003/ (N7)

The low-level decoder might fall into an infinite decoding loop for
various reasons, the simplest being an infinite direct loop reached due
to wrong handling of self-modified code in the kernel, e.g. it might
reach

```
0x0A: pause
0x0C: jump to 0x0A
```

In this case, all the code is sequential and requires no packets to be
decoded. The low-level decoder would produce an output like the
following

```
0x0A: pause
0x0C: jump to 0x0A
0x0A: pause
0x0C: jump to 0x0A
0x0A: pause
0x0C: jump to 0x0A
... infinite amount of times
```

These cases require stopping the decoder to avoid infinite work and signal this
at least as a trace error.

- Add a check that breaks decoding of a single PSB once 500k instructions have been decoded since the last packet was processed.
- Add a check that looks for infinite loops after certain amount of instructions have been decoded since the last packet was processed.
- Add some `settings` properties for tweaking the thresholds of the checks above. This is also nice because it does the basic work needed for future settings.
- Add an AnomalyDetector class that inspects the DecodedThread and the libipt decoder in search for anomalies. These anomalies are then signaled as fatal errors in the trace.
- Add an ErrorStats class that keeps track of all the errors in a DecodedThread, with a special counter for fatal errors.
- Add an entry for decoded thread errors in the `dump info` command.

Some notes are added in the code and in the documention of the settings,
so please read them.

Besides that, I haven't been unable to create a test case in LLVM style, but
I've found an anomaly in the thread #12 of the trace
72533820-3eb8-4465-b8e4-4e6bf0ccca99 at Meta. We have to figure out how to
artificially create traces with this kind of anomalies in LLVM style.

With this change, that anomalous thread now shows:

```
(lldb)thread trace dump instructions 12 -e -i 23101

thread #12: tid = 8
    ...missing instructions
    23101: (error) anomalous trace: possible infinite loop detected of size 2
  vmlinux-5.12.0-0_fbk8_clang_6656_gc85768aa64da`panic_smp_self_stop + 5 [inlined] rep_nop at processor.h:13:2
    23100: 0xffffffff81342785    pause
  vmlinux-5.12.0-0_fbk8_clang_6656_gc85768aa64da`panic_smp_self_stop + 7 at panic.c:87:2
    23099: 0xffffffff81342787    jmp    0xffffffff81342785        ; <+5> [inlined] rep_nop at processor.h:13:2
  vmlinux-5.12.0-0_fbk8_clang_6656_gc85768aa64da`panic_smp_self_stop + 5 [inlined] rep_nop at processor.h:13:2
    23098: 0xffffffff81342785    pause
  vmlinux-5.12.0-0_fbk8_clang_6656_gc85768aa64da`panic_smp_self_stop + 7 at panic.c:87:2
    23097: 0xffffffff81342787    jmp    0xffffffff81342785        ; <+5> [inlined] rep_nop at processor.h:13:2
  vmlinux-5.12.0-0_fbk8_clang_6656_gc85768aa64da`panic_smp_self_stop + 5 [inlined] rep_nop at processor.h:13:2
    23096: 0xffffffff81342785    pause
  vmlinux-5.12.0-0_fbk8_clang_6656_gc85768aa64da`panic_smp_self_stop + 7 at panic.c:87:2
    23095: 0xffffffff81342787    jmp    0xffffffff81342785        ; <+5> [inlined] rep_nop at processor.h:13:2
```

It used to be in an infinite loop where the decoder never stopped.

Besides that, the dump info command shows

```
(lldb) thread trace dump info 12

 Errors:
    Number of individual errors: 32
      Number of fatal errors: 1
      Number of other errors: 31
```

and in json format

```
(lldb) thread trace dump info 12 -j

 "errors": {
      "totalCount": 32,
      "libiptErrors": {},
      "fatalErrors": 1,
      "otherErrors": 31
    }
```

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

This reverts commit 2f88268f.

I will take a look what's happening with vectorization.mlir and why it
works on my machine and not upstream. Reverting for now.