The implementation of Messages with forward_list<> makes some
nonstandard assumptions about the validity of iterators that don't
hold up with MSVC's implementation.  Use list<> instead.  The
measured performance is comparable.

This change obviated a distinction between two member functions
of Messages, and the uses of one have been replaced with calls
to the other.

Similar usage in CharBuffer was also replaced for consistency.

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

Non-mechanical changes:
 - Added FIXME to StringLiteral to cover multi-token string literals.
 - LiteralExpression::getLiteralToken() is gone. (It was never called)
   This is because we don't codegen methods in Alternatives
   It's conceptually suspect if we consider multi-token string literals, though.

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

Following discussion in D91193, a change made in D88792 was not quite right.
This restores the message argument, and switches from `expect` to `runCmd`.

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

Bold and fixed-width do not appear to mix well.

Fixes some formatting and wording, and adds a roadmap section.

We need to be able to call function pointers. Inline the dispatch
function.

Also inline the context projection function.

Transfer debug locations from the suspend point to the inlined functions.

Use the function argument index instead of the function argument in
coro.id.async. This solves any spurious use issues.

Coerce the arguments of the tail call function at a suspend point. The LLVM
optimizer seems to drop casts leading to a vararg intrinsic.

rdar://70097093

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

Some targets may add required passes via
TargetMachine::registerPassBuilderCallbacks(). We need to run those even
under -O0. As an example, BPFTargetMachine adds
BPFAbstractMemberAccessPass, a required pass.

This also allows us to clean up BackendUtil.cpp (and out-of-tree Rust
usage of the NPM) by allowing us to share added passes like coroutines
and sanitizers between -O0 and other optimization levels.

Since callbacks may end up not adding passes, we need to check if the
pass managers are empty before adding them, so PassManager now has an
isEmpty() function. For example, polly adds callbacks but doesn't always
add passes in those callbacks, so this is necessary to keep
-debug-pass-manager tests' output from changing depending on if polly is
enabled or not.

Tests are a continuation of those added in
https://reviews.llvm.org/D89083.

Reviewed By: asbirlea, Meinersbur

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

except where they are necessary to disambiguate the target.

This substantially improves diagnostics from the standard library,
which are otherwise full of `::__1::` noise.

arguments of types by default.

This somewhat improves the worst-case printing of types like
std::string, std::vector, etc., where many irrelevant default arguments
can be included in the type as printed if we've lost the type sugar.

- Add verbose logging of payloads
- Add public logging of request summaries
- fix non-logging of messages in request scopes (oops!)
- add test for public/non-public logging, extending pipeline_helper a bit.

We've accumulated quite a lot of duplication in the request handlers by now.
I should factor that out, but not in this patch...

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

Implement heterogenous lookup for unordered containers, including the
refinement from P1690R1.

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

This patch adds support for accumulator/unprimed accumulator
register copy, spill and restore for MMA.

Authored By: Baptiste Saleil

Reviewed By: #powerpc, bsaleil, amyk

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

Operand tree forwarding can cause the change of an access kind; in
particular change from a scalar kind to an array kind if the scalar
dependency is not necessary. Such an access cannot and doesn't need to
be forwarded anymore.

Fixes llvm.org/PR48034

Print to dbgs() any taken action.

Also, read-only scalars do not require any action unless
-polly-analyze-read-only-scalars=true is used. Better refect this by
using ForwardingAction::triviallyForwardable and thus not bumping the
statistics.

Avoid requiring an actual MemoryBuffer in ComputePreambleBounds, when
a MemoryBufferRef will do just fine.

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

Previously a corrupted index shard could cause us to resize arrays to an
arbitrary int32. This tends to be a huge number, and can render the
system unresponsive.

Instead, cap this at the amount of data that might reasonably be read
(e.g. the #bytes in the file). If the specified length is more than that,
assume the data is corrupt.

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

We include <exception>, which includes <cstdlib> unconditionally anyway.

This has been a long-standing TODO item, however we have now been requiring
a monorepo layout to build libc++ and libc++abi for a while now. Hence,
we can fix this code duplication issue now.

Note that it's still not super pretty to reach into libc++ to include
headers, but it's better than having duplicated code which can get out
of sync.

Avoid a spurious error message about a dummy procedure reference
in a specification expression by restructuring the handling of
use-associated and host-associated symbols.

Updated to fix a circular dependence between shared library
binaries that was introduced by the original patch.

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

Previously the inliner did a bit of a hack by adding ref edges for all
new edges introduced by performing an inline before calling
updateCGAndAnalysisManagerForPass(). This was because
updateCGAndAnalysisManagerForPass() didn't handle new non-trivial call
edges.

This adds handling of non-trivial call edges to
updateCGAndAnalysisManagerForPass().  The inliner called
updateCGAndAnalysisManagerForFunctionPass() since it was handling adding
newly introduced edges (so updateCGAndAnalysisManagerForPass() would
only have to handle promotion), but now it needs to call
updateCGAndAnalysisManagerForCGSCCPass() since
updateCGAndAnalysisManagerForPass() is now handling the new call edges
and function passes cannot add new edges.

We follow the previous path of adding trivial ref edges then letting promotion
handle changing the ref edges to call edges and the CGSCC updates. So
this still does not allow adding call edges that result in an addition
of a non-trivial ref edge.

This is in preparation for better detecting devirtualization. Previously
since the inliner itself would add ref edges,
updateCGAndAnalysisManagerForPass() would think that promotion and thus
devirtualization had happened after any sort of inlining.

Reviewed By: asbirlea

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

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.