The Itanium CXX ABI grammer has been extended to support parameterized
vendor extended types [1].

This patch updates Clang's mangling for matrix types to use the new
extension.

[1] https://github.com/itanium-cxx-abi/cxx-abi/commit/b359d28971bdb961dd9b61bd0ef8c884452b4740

Reviewed By: rjmccall

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

Some changes were made to the libc++abi new/delete definitions, but
they were not copied back to the libc++ definition. It sucks that we
have this duplication, but for now at least let's keep them in sync.

When there is full fp16 support, there is no reason to widen 16-bit
G_FCONSTANTs to 32 bits. Mark them as legal in this case.

Also, we currently import a pattern for materializing a 16-bit 0.0.
Add a testcase showing we select it.

(All other 16-bit G_FCONSTANTS are not yet selected.)

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

Support a vector register constraint in inline asm of clang.
Add a regression test also.

Reviewed By: simoll

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

Qualify definitions with `clang::` rather than opening/closing a namespace.

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

F18 clause 5.3.3 explicitly allows labels on program unit END statements.
Label resolution code accounts for this for singleton program units,
but incorrectly generates an error for host subprograms with internal
subprograms.

   subroutine s(n)
      call s1(n)
      if (n == 0) goto 88 ! incorrect error
      print*, 's'
   contains
      subroutine s1(n)
         if (n == 0) goto 77 ! ok
         print*, 's1'
   77 end subroutine s1
   88 end

Label resolution code makes a sequential pass over an entire file to
collect label information for all subprograms, followed by a pass through
that information for semantics checks.  The problem is that END statements
may be separated from prior subprogram code by internal subprogram
definitions, so an END label can be associated with the wrong subprogram.

There are several ways to fix this.  Labels are always local to a
subprogram.  So the two separate passes over the entire file could probably
instead be interleaved to perform analysis on a subprogram as soon as the
end of the subprogram is reached, using a small stack.  The stack structure
would account for the "split" code case.  This might work.

It is possible that there is some not otherwise apparent advantage to
the current full-file pass design.  The parse tree has productions that
provide access to a subprogram END statement "in advance".  An alternative
is to access this information to solve the problem.  This PR implements
this latter option.

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

Before the change, DFSan always does the propagation. W/o
origin tracking, it is harder to understand such flows. After
the change, the flag is off by default.

Reviewed-by: morehouse
Differential Revision: https://reviews.llvm.org/D91234

This is consistent with what's done in locale.cpp, and it ensures that
we get the default rune table whenever _LIBCPP_PROVIDES_DEFAULT_RUNE_TABLE
is defined, regardless of the actual platform.

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

Buildbot failed on Windows
http://lab.llvm.org:8011/#/builders/83/builds/693

Error: On Windows, std::future can't hold an Expected, as it doesn't have a default
constructor.

Solution: Use std::future<bool> instead of std::future<Expected<T>>

Implicitly typed references to external functions are applying
the IMPLICIT typing rules of the global scope in which their
symbols were created, not the IMPLICIT typing rules in force in
the scope from which they were referenced.

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

This reverts commit 09248a5d.

Some builds are broken. I suspect a `static constexpr` in a class missing a
definition out of class (required pre-c++17).

The deadlock/race happens when primary thread gets initz lock and tries to join
the worker thread which waits for the same lock in TLS key destructor.
The patch removes the lock and the code of setting TLS value which needed
the lock. Also removed setting TLS from __kmp_unregister_root_current_thread.

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

It's nonstandard, but commonly implemented.

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

Previous the textual form of the pass pipeline would implicitly nest,
instead we opt for the explicit form here: this has less surprise.

This also avoids asserting in the bindings when passing a pass pipeline
with incorrect nesting.

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

If block A and B are in different regions and region of A is not an ancestor of
B, either A is included in region of B or the two regions are disjoint. In both
case A doesn't post-dominate B.

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

Avoid dereferencing a possibly uninitialized pointer as mentioned in D91280.

This patch allows to pass the OpenMP runtime tests after configuring with
`cmake . -DOPENMP_TEST_FLAGS:STRING="-Werror"`.
The warnings for OMPT tests are addressed in D90752.

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

This doesn't add functionality, but just adds the new types and renames the
master callback to masked callback.

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

Reviewed-by: morehouse
Differential Revision: https://reviews.llvm.org/D91235

Adds test coverage for ThreadPlanStepInRange::SetAvoidRegexp, but
disables the test on Windows.

See:
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/Target/ThreadPlanStepInRange.cpp.html#L309

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

Makes diff in next commit more readable.

Just use default CHECK

Just use default CHECK

* Used in npcomp to cast Python objects via the C-API.

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

Depends on D89283.

The goal of this packet (jTraceGetSupportedType) is to be able to query the gdb-server for the tracing technology that can work for the current debuggeer, which can make the user experience simpler but allowing the user to simply type

  thread trace start

to start tracing the current thread without even telling the debugger to use "intel-pt", for example. Similarly, `thread trace start [args...]` would accept args beloging to the working trace type.

Also, if the user typed

  help thread trace start

We could directly show the help information of the trace type that is supported for the target, or mention instead that no tracing is supported, if that's the case.

I added some simple tests, besides, when I ran this on my machine with intel-pt support, I got

  $ process plugin packet send "jTraceSupportedType"
    packet: jTraceSupportedType
  response: {"description":"Intel Processor Trace","pluginName":"intel-pt"}

On a machine without intel-pt support, I got

  $ process plugin packet send "jTraceSupportedType"
    packet: jTraceSupportedType
  response: E00;

Reviewed By: clayborg, labath

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

xnu coredumps include an LC_IDENT load command. It's helpful to be able
to just ignore these. IIUC an interested client can grab the identifier
using the MachOObjectFile::load_commands() API.

The status quo is that llvm bails out when it finds an LC_IDENT because
the command is obsolete (see isLoadCommandObsolete).

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

BatchAA produces an incorrect result, because a result based on
a temporary phi noalias assumption is cached.

Just use default CHECK

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

We were creating RISCVISD::SELECT_CC nodes with Glue output that was never being used, and the tablegen SDNode had the SDNPInGlue flag instead of the SDNPOutGlue flag.

Since we don't seem to need the Glue just get rid of it from both places.

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

The manual selection code for add/sub was not checking if it was possible to
fold in shifts + extends (the *rx opcode variants).

As a result, we could never select things like

```
cmp x1, w0, uxtw #2
```

Because we don't import any patterns for compares.

This adds support for the arithmetic shifted register forms and updates tests
for instructions selected using `emitADD`, `emitADDS`, and `emitSUBS`.

This is a 0.1% geomean code size improvement on SPECINT2000 at -Os.

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