dependent contexts.

We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which would lead to
crashes and other misbehavior.

his change splits the copy constructor up inlining short initialization, and explicitly outlining long initialization into __init_copy_ctor_external() which is the externally instantiated slow path.

For unstable ABI, this has the following changes:

remove basic_string(const basic_string&)
remove basic_string(const basic_string&, const Allocator&)
add __init_copy_ctor_external(const value_type*, size_type)
Quick local benchmark for Copy:

Master
```
---------------------------------------------------------------
Benchmark                    Time             CPU   Iterations
---------------------------------------------------------------
BM_StringCopy_Empty       3.50 ns         3.51 ns    199326720
BM_StringCopy_Small       3.50 ns         3.51 ns    199510016
BM_StringCopy_Large       15.7 ns         15.7 ns     45230080
BM_StringCopy_Huge        1503 ns         1503 ns       464896
```

```
---------------------------------------------------------------
Benchmark                    Time             CPU   Iterations
---------------------------------------------------------------
BM_StringCopy_Empty       1.99 ns         2.00 ns    356471808
BM_StringCopy_Small       3.29 ns         3.30 ns    203425792
BM_StringCopy_Large       13.3 ns         13.3 ns     52948992
BM_StringCopy_Huge        1472 ns         1472 ns       475136
```

Author: Martijn Vels <martijn.vels@gmail.com>

Reviewers: EricWF, mclow.list

Tags: #llvm

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

This option can be used to for JITLink to link as-if the target memory slab were
allocated at a specific start address. This can be used to both verify that
cross-address space linking is working correctly, and to ensure that certain
address-sensitive optimizations (e.g. GOT and stub elimination) either do or do
not fire, depending on the requirements of the test case.

This argument is only valid for testing in conjunction with -noexec -slab-alloc,
and will produce an error if used without those arguments.

Summary:
Fix misidentification of C# array subscript operators.

Reviewers: krasimir

Reviewed By: krasimir

Subscribers: cfe-commits, MyDeveloperDay

Tags: #clang-format, #clang

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

Summary:
Re-use token type `TT_AttributeColon` for C# attribute target colons.

Reviewers: krasimir

Reviewed By: krasimir

Subscribers: MyDeveloperDay, cfe-commits

Tags: #clang-format, #clang

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

Check the fast math flag before the more expensive loop check.

The computation here didn't really make sense to me, and reported
wildy different results depending on the flat work group size
attribute.

I think this should really report a range derived from the possible
work group size bounds, and only allow an occupancy that is a multiple
of the group size.

The -fsystem-module flag is used when explicitly building a module. It
forces the module to be treated as a system module. This is used when
converting an implicit build to an explicit build to match the
systemness the implicit build would have had for a given module.

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

Summary:
https://gist.github.com/modocache/ed7c62f6e570766c0f39b35dad675c2f
is an example of a small C++ program that uses C++20 coroutines that
is difficult to debug, due to the loss of debug info for variables that
"spill" across coroutine suspension boundaries. This patch addresses
that issue by inserting 'llvm.dbg.declare' intrinsics that point the
debugger to the variables' location at an offset to the coroutine frame.

With this patch, I confirmed that running the 'frame variable' commands in
https://gist.github.com/modocache/ed7c62f6e570766c0f39b35dad675c2f at
the specified breakpoints results in the correct values being printed
for coroutine frame variables 'i' and 'j' when using an lldb built from
trunk, as well as with gdb 8.3 (lldb 9.0.1, however, could not print the
values). The added test case also verifies this improved behavior.

The existing coro-debug.ll test case is also modified to reflect the
locations at which Clang actually places calls to 'dbg.declare', and
additional checks are added to ensure this patch works as intended in that
example as well.

Reviewers: vsk, jmorse, GorNishanov, lewissbaker, wenlei

Subscribers: EricWF, aprantl, hiraditya, llvm-commits

Tags: #llvm

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

Summary: This patch renames the "llvm-gsym" tool directory to "llvm-gsymutil". Dependencies are also reduced to the bare minimum for llvm-gsymutil.

Reviewers: aprantl, thakis

Subscribers: mgorny, llvm-commits

Tags: #llvm

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

Summary:
This change checks for the return type in the frontend and adds a flag
to the DISubroutineType to indicate that the option should be added in
CodeViewDebug.

Previously function types sometimes appeared twice in the PDB: once with
"returns cxx udt" and once without.
See https://bugs.llvm.org/show_bug.cgi?id=44785.

Reviewers: rnk, asmith

Subscribers: hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

reinterpret_cast'ing the block base address directly to a uint64_t leaves the
high bits in an implementation-defined state, but JITLink expects them to be
zero. Switching to pointerToJITTargetAddress for the cast should fix this.

This should fix the jitlink test failures that we have seen on some of the
32-bit testers.

Summary:
Previously, we would, for an empty file, print the somewhat confusing
  Assertion `tok == curTok [...]' failed.
With this change, we now print
  Parse error [...]: expected 'def' [...]

This only affects the parser from chapters 1-6, since the more advanced
chapter 7 parser is actually able to generate an empty module from an
empty file.  Nonetheless, this commit also adds the additional check to
the chapter 7 parser, for consistency.

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

Summary: This allows for attaching the attribute to CmpF as a proper argument, and thus enables the removal of a bunch of c++ code.

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

Two issues:
- Need to add env prefix to be compatible with the lit internal shell
- Need to quote the colon in Windows paths with '"%t.supp"'

div-by-0 -> Inf
The math ops are 'fast' so 'ninf' applies and the whole thing is undef.

There should not be an exception allowing debug entry values to be
placed after a terminator.

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

This fixes a miscompile that happened because a DBG_VALUE interfered
with the MachineOutliner's liveness analysis.

Inserting a DBG_VALUE after a terminator breaks predicates on MBB such
as isReturnBlock(). And the resulting DBG_VALUE cannot be "live".

I plan to introduce a MachineVerifier check for this situation in a
follow up.

rdar://59859175

Testing: check-llvm, LNT build with a stage2 compiler & entry values
enabled

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

[clangd] Handle go-to-definition in macro invocations where the target appears in the expansion multiple times

Fixes https://github.com/clangd/clangd/issues/234

Reviewers: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

Lower priority of __tgt_register_lib in order to make sure that __tgt_register_requires is called before loading a libomptarget plugin.
We want to know beforehand which requirements the user has asked for so that upon loading the plugin libomptarget can report how many devices there are that can satisfy these requirements.

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

Drop trailing spaces and reflow text to fit 80 columns.

uops.info says these should be 15 cycle instructions. Uops.info also shows the 512-bit form uses port 0 and 5 for both register and memory. We had memory using 0 and 1.

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

For ODS generated operations enable querying whether there is a derived
attribute with a given name.

Rollforward of commit 5aa57c28 without using llvm::is_contained.

This reverts commit 78a734e2.

This reverts commit 9989b859.

This reverts commit 3270ea90.

Summary: Attempt to add more attributes for runtime calls.

Reviewers: jdoerfertA, ggeorgakoudis, lebedev.ri, dreachem

Subscribers:

Haibo told me he didn't have any issues with Python 3.8 and I was able
to confirm that. Even though we don't have bot running with 3.8, I think
it safe to mark it as supported in the docs.

Added basic support (parsing/sema/serialization) for 'update' clause in
'depobj' directive.

Summary: I don't see why we want to keep that code around.

Reviewers: #lldb, JDevlieghere

Reviewed By: #lldb, JDevlieghere

Subscribers: davide

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

[X86] Always emit an integer vbroadcast_load from lowerBuildVectorAsBroadcast regardless of AVX vs AVX2

If we go with D75412, we no longer depend on the scalar type directly. So we don't need to avoid using i64. We already have AVX1 fallback patterns with i32 and i64 scalar types so we don't need to avoid using integer types on AVX1.

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

Also add a DAG combine to combine different sized broadcasts from
constant pool to avoid a regression.

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

Summary: This patch adds an analysis pass to collect loop nests and
summarize properties of the nest (e.g the nest depth, whether the nest
is perfect, what's the innermost loop, etc...).

The motivation for this patch was discussed at the latest meeting of the
LLVM loop group (https://ibm.box.com/v/llvm-loop-nest-analysis) where we
discussed
the unimodular loop transformation framework ( “A Loop Transformation
Theory and an Algorithm to Maximize Parallelism”, Michael E. Wolf and
Monica S. Lam, IEEE TPDS, October 1991). The unimodular framework
provides a convenient way to unify legality checking and code generation
for several loop nest transformations (e.g. loop reversal, loop
interchange, loop skewing) and their compositions. Given that the
unimodular framework is applicable to perfect loop nests this is one
property of interest we expose in this analysis. Several other utility
functions are also provided. In the future other properties of interest
can be added in a centralized place.
Authored By: etiotto
Reviewer: Meinersbur, bmahjour, kbarton, Whitney, dmgreen, fhahn,
reames, hfinkel, jdoerfert, ppc-slack
Reviewed By: Meinersbur
Subscribers: bryanpkc, ppc-slack, mgorny, hiraditya, llvm-commits
Tag: LLVM
Differential Revision: https://reviews.llvm.org/D68789