[NFC] Test commit.
Testing llvm commit access only.

llvm-svn: 374174

[scudo][standalone] Get statistics in a char buffer

Summary:
Following up on D68471, this CL introduces some `getStats` APIs to
gather statistics in char buffers (`ScopedString` really) instead of
printing them out right away. Ultimately `printStats` will just
output the buffer, but that allows us to potentially do some work
on the intermediate buffer, and can be used for a `mallocz` type
of functionality. This allows us to pretty much get rid of all the
`Printf` calls around, but I am keeping the function in for
debugging purposes.

This changes the existing tests to use the new APIs when required.

I will add new tests as suggested in D68471 in another CL.

Reviewers: morehouse, hctim, vitalybuka, eugenis, cferris

Reviewed By: morehouse

Subscribers: delcypher, #sanitizers, llvm-commits

Tags: #llvm, #sanitizers

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

llvm-svn: 374173

[clang-format] Update noexcept reference qualifiers detection

Summary:
r373165 fixed an issue where a templated noexcept member function with a
reference qualifier would be indented more than expected:
```
// Formatting produced with LLVM style with AlwaysBreakTemplateDeclarations: Yes

// before r373165:
struct f {
  template <class T>
      void bar() && noexcept {}
};

// after:
struct f {
  template <class T>
  void bar() && noexcept {}
};

```
The way this is done is that in the AnnotatingParser in
`lib/FormatTokenAnnotator.cpp` the determination of the usage of a `&` or `&&`
(the line in determineTokenType

```
Current.Type = determineStarAmpUsage(...
```
is not performed in some cases anymore, combining with a few additional related
checks afterwards. The net effect of these checks results in the `&` or `&&`
token to start being classified as `TT_Unknown` in cases where before `r373165`
it would be classified as `TT_UnaryOperator` or `TT_PointerOrReference` by
`determineStarAmpUsage`.

This inadvertently caused 2 classes of regressions I'm aware of:

- The address-of `&` after a function assignment would be classified as
  `TT_Unknown`, causing spaces to surround it, disregarding style options:
```
// before r373165:
void (*fun_ptr)(void) = &fun;

// after:
void (*fun_ptr)(void) = & fun;
```

- In cases where there is a function declaration list -- looking macro between
  a template line and the start of the function declaration, an `&` as part of
  the return type would be classified as `TT_Unknown`, causing spaces to
  surround it:
```
// before r373165:
template <class T>
DEPRECATED("lala")
Type& foo();

// after:
template <class T>
DEPRECATED("lala")
Type & foo();
```

In these cases the problems are rooted in the skipping of the classification of
a `&` (and similarly `&&`) by determineStarAmpUsage which effects the formatting
decisions later in the pipeline.

I've looked into the goal of r373165 and noticed that replacing `noexcept` with
`const` in the given example produces no extra indentation with the old code:
```
// before r373165:
struct f {
  template <class T>
  int foo() & const {}
};

struct f {
  template <class T>
      int foo() & noexcept {}
};
```

I investigated how clang-format annotated these two examples differently to
determine the places where the processing of both diverges in the pipeline.
There were two places where the processing diverges, causing the extra indent in
the `noexcept` case:
1. The `const` is annotated as a `TT_TrailingAnnotation`, whereas `noexcept`
   is annotated as `TT_Unknown`. I've updated the `determineTokenType` function
   to account for this by adding a missing `tok:kw_noexcept` to the clause that
   marks a token as `TT_TrailingAnnotation`.
2. The `&` in the second example is wrongly identified as `TT_BinaryOperator`
   in `determineStarAmpUsage`. This is the reason for the extra indentation --
   clang-format gets confused and thinks this is an expression.
   I've updated `determineStarAmpUsage` to check for `tok:kw_noexcept`.

With these two updates in place, the additional parsing introduced by r373165
becomes unnecessary and all added tests pass (with updates, as now clang-format
respects the style configuration for spaces around the `&` in the test
examples).
I've removed these additions and added regression tests for the cases above.

Reviewers: AndWass, MyDeveloperDay

Reviewed By: MyDeveloperDay

Subscribers: cfe-commits

Tags: #clang, #clang-format

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

llvm-svn: 374172

Fix Wdocumentation unknown parameter warning. NFCI.

llvm-svn: 374171

[llvm-exegesis] Ensure that ExecutableFunction are aligned.

Summary: Experiments show that this is the alignment we get (for ELF+Linux), but let's ensure that we have it.

Reviewers: gchatelet

Subscribers: tschuett, llvm-commits

Tags: #llvm

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

llvm-svn: 374170

Add and adjust saturating tests. NFC

This adds some extra testing to the existing [su][add/sub]_sat X86 and AArch64
tests and adds equivalent tests for ARM.

llvm-svn: 374169

[clangd] Make sure ReplyCallbacks are destroyed before RequestCancelersMutex

Summary:
After rL374163, replycallbacks might have a cancellable context, which
will try to access RequestCancellers on destruction. See
http://45.33.8.238/mac/1245/step_7.txt for a sample failure.

Reviewers: sammccall

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

Tags: #clang

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

llvm-svn: 374168

[clang-offload-bundler] Support `.cui` and `.d`.

Reviewers: tra, yaxunl

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 374167

[LV] Emitting SCEV checks with OptForSize

When optimising for size and SCEV runtime checks need to be emitted to check
overflow behaviour, the loop vectorizer can run in this assert:

  LoopVectorize.cpp:2699: void llvm::InnerLoopVectorizer::emitSCEVChecks(
  llvm::Loop *, llvm::BasicBlock *): Assertion `!BB->getParent()->hasOptSize()
  && "Cannot SCEV check stride or overflow when opt

We should not generate predicates while optimising for size because
code will be generated for predicates such as these SCEV overflow runtime
checks.

This should fix PR43371.

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

llvm-svn: 374166

[mips] Rename local variable. NFC

llvm-svn: 374165

[mips] Split expandLoadImmReal into multiple methods. NFC

The `expandLoadImmReal` handles four different and almost non-overlapping
cases: loading a "single" float immediate into a GPR, loading a "single"
float immediate into a FPR, and the same couple for a "double" float
immediate.

It's better to move each `else if` branch into separate methods.

llvm-svn: 374164

[clangd] Propagate context into reply handlers

llvm-svn: 374163

[llvm-exegesis] Fix r374158

Some bots complain about missing 'class':

LlvmState.h:70:40: error: declaration of ‘std::unique_ptr<const llvm::TargetMachine> llvm::exegesis::LLVMState::TargetMachine’ [-fpermissive]
   std::unique_ptr<const TargetMachine> TargetMachine;

llvm-svn: 374162

[CostModel][X86] Add tests for insertelement to non-immediate vector element indices

llvm-svn: 374161

[CostModel][X86] Add tests for extractelement from non-immediate vector element indices

llvm-svn: 374160

[ARM] Add saturating arithmetic tests for MVE. NFC

llvm-svn: 374159

[llvm-exegesis][NFC] Remove extra `llvm::` qualifications.

Summary: Second patch: in the lib.

Reviewers: gchatelet

Subscribers: nemanjai, tschuett, MaskRay, mgrang, jsji, llvm-commits

Tags: #llvm

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

llvm-svn: 374158

[llvm-exegesis][NFC] Remove extra `llvm::` qualifications.

Summary: First patch: in unit tests.

Subscribers: nemanjai, tschuett, MaskRay, jsji, llvm-commits

Tags: #llvm

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

llvm-svn: 374157

[mips] Set default float ABI to "soft" on FreeBSD

Initial patch by Kyle Evans.

Fix PR43596

llvm-svn: 374154

[DebugInfo] Enable call site debug info for ARM and AArch64

ARM and AArch64 SelectionDAG support for tacking parameter forwarding
register is implemented so we can allow clang invocations for those two
targets.
Beside that restrict debug entry value support to be emitted for
LimitedDebugInfo info and FullDebugInfo. Other types of debug info do
not have functions nor variables debug info.

Reviewers: aprantl, probinson, dstenb, vsk

Reviewed By: vsk

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

llvm-svn: 374153

[Sema] Emit diagnostics for uncorrected delayed typos at the end of TU

Summary:
Instead of asserting all typos are corrected in the sema destructor.

The sema destructor is not run in the common case of running the compiler
with the -disable-free cc1 flag (which is the default in the driver).

Having this assertion led to crashes in libclang and clangd, which are not
reproducible when running the compiler.

Asserting at the end of the TU could be an option, but finding all
missing typo correction cases is hard and having worse diagnostics instead
of a failing assertion is a better trade-off.

For more discussion on this, see:
https://lists.llvm.org/pipermail/cfe-dev/2019-July/062872.html

Reviewers: sammccall, rsmith

Reviewed By: rsmith

Subscribers: usaxena95, dgoldman, jkorous, vsapsai, rnk, kadircet, cfe-commits

Tags: #clang

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

llvm-svn: 374152

Revert r374006: Reland 'Add VFS support for sanitizers' blacklist'

Also revert follow-up changes to the test.
Reason: the patch breaks our internal clang-tidy integration.

It's also unclear why we should use getRealPath instead of plumbing the
VFS to SanitizerBlacklist, see original commit thread of cfe-commits for
a discussion.

llvm-svn: 374151

[TableGen] Fix crash when using HwModes in CodeEmitterGen

When an instruction has an encoding definition for only a subset of
the available HwModes, ensure we just avoid generating an encoding
rather than crash.

llvm-svn: 374150

[llvm-exegesis] Add missing std::move in rL374146.

This was breaking some bots:

/home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/llvm/include/llvm/Support/Error.h:483:5:   required from ‘llvm::Expected<T>::Expected(OtherT&&, typename std::enable_if<std::is_convertible<_Rep2, _Rep>::value>::type*) [with OtherT = std::vector<llvm::exegesis::CodeTemplate>&; T = std::vector<llvm::exegesis::CodeTemplate>; typename std::enable_if<std::is_convertible<_Rep2, _Rep>::value>::type = void]’
/home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/llvm/tools/llvm-exegesis/lib/X86/Target.cpp:238:20:   required from here
/usr/include/c++/6/bits/stl_construct.h:75:7: error: use of deleted function ‘llvm::exegesis::CodeTemplate::CodeTemplate(const llvm::exegesis::CodeTemplate&)’
     { ::new(static_cast<void*>(__p)) _T1(std::forward<_Args>(__args)...); }
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

llvm-svn: 374149

Unify the two CRC implementations

David added the JamCRC implementation in r246590. More recently, Eugene
added a CRC-32 implementation in r357901, which falls back to zlib's
crc32 function if present.

These checksums are essentially the same, so having multiple
implementations seems unnecessary. This replaces the CRC-32
implementation with the simpler one from JamCRC, and implements the
JamCRC interface in terms of CRC-32 since this means it can use zlib's
implementation when available, saving a few bytes and potentially making
it faster.

JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef.
This patch changes it to ArrayRef<uint8_t> which I think is the best
choice, and simplifies a few of the callers nicely.

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

llvm-svn: 374148

[llvm-exegesis][NFC] Fix rL374146.

Remove extra semicolon: Target.cpp:187:2: warning: extra ‘;’ [-Wpedantic]

llvm-svn: 374147

[llvm-exegesis] Explore LEA addressing modes.

Summary:
This will help for PR32326.

This shows the well-known issue with `RBP` and `R13` as base registers.

Reviewers: gchatelet

Subscribers: tschuett, llvm-commits, RKSimon, andreadb

Tags: #llvm

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

llvm-svn: 374146

[lldb] Don't crash when the ASTImporter produces diagnostics but instead log them.

When playing with the C++ module prototype I noticed I can get LLDB to crash
by making a result type that depends on __make_integer_seq (a BuiltinTemplate)
which is not supported by the ASTImporter yet. This causes the ASTImporter to emit
a diagnostic when copying the type to the ScratchASTContext. As deporting the result
type is done after we are done parsing and the Clang's diagnostic engine asserts that
it can only be used during parsing, it crashes LLDB while trying to render the diagnostic
in the HandleDiagnostic method of ClangDiagnosticManagerAdapter.

This patch just moves the HandleDiagnostic call to Clang behind our check that we still
have a DiagnosticManager (which we remove after parsing) which prevents the assert
from firing. We also shouldn't ignore such diagnostics, so I added a log statement for
them.

There doesn't seem to way to test this as these diagnostic only happen when we copy
a node that's not supported by the ASTImporter which should never happen once
we can copy everything with the ASTImporter, so every test case we add here will
eventually become invalid.

(Note that most of this diff is just whitespace changes as we now use an early exit
instead of a huge 'if' block).

llvm-svn: 374145

Revert r374139, "[dsymutil] Fix handling of common symbols in multiple object files."

The added test files ("com", "com1.o", "com2.o") are reserved names on
Windows, and makes 'git checkout' fail with a filesystem error.

llvm-svn: 374144

[llvm-exegesis][NFC] Remove unecessary `using llvm::` directives.

We've been in namespace llvm for at least a year.

llvm-svn: 374143

Use lld-link instead of llvm-dlltool to create an implib

Suggested by Martin Storsjö.

llvm-svn: 374142

[lld] Don't create hints-section if Hint/Name Table is empty

Fixes assert in addLinkerModuleCoffGroup() when using by-ordinal imports
only.

Patch by Stefan Schmidt.

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

llvm-svn: 374140

[dsymutil] Fix handling of common symbols in multiple object files.

For common symbols the linker emits only a single symbol entry in the
debug map. This caused dsymutil to not relocate common symbols when
linking DWARF coming form object files that did not have this entry.
This patch fixes that by keeping track of common symbols in the object
files and synthesizing a debug map entry for them using the address from
the main binary.

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

llvm-svn: 374139

[TypeSize] Fix module builds (cassert)

TypeSize.h uses `assert` statements without including
the <cassert> header first which leads to failures
in modular builds.

llvm-svn: 374138

Optimize operator=(const basic_string&) for tail call.

Patch by Martijn Vels (mvels@google.com)
Reviewed as https://reviews.llvm.org/D68276

This is a non trivial win for externally templated assignment operator.

x86 without tail call (current libc++)

0000000000000000 <std::string::operator=(std::string const&)>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   53                      push   %rbx
   5:   50                      push   %rax
   6:   48 89 fb                mov    %rdi,%rbx
   9:   48 39 f7                cmp    %rsi,%rdi
   c:   74 17                   je     25 <std::string::operator=(std::string const&)+0x25>
   e:   0f b6 56 17             movzbl 0x17(%rsi),%edx
  12:   84 d2                   test   %dl,%dl
  14:   79 07                   jns    1d <std::string::operator=(std::string const&)+0x1d>
  16:   48 8b 56 08             mov    0x8(%rsi),%rdx
  1a:   48 8b 36                mov    (%rsi),%rsi
  1d:   48 89 df                mov    %rbx,%rdi
  20:   e8 00 00 00 00          callq  25 <std::string::operator=(std::string const&)+0x25>
  25:   48 89 d8                mov    %rbx,%rax
  28:   48 83 c4 08             add    $0x8,%rsp
  2c:   5b                      pop    %rbx
  2d:   5d                      pop    %rbp
  2e:   c3                      retq

After:

0000000000000000 <std::string::operator=(std::string const&)>:
   0:   48 39 f7                cmp    %rsi,%rdi
   3:   74 14                   je     19 <std::string::operator=(std::string const&)+0x19>
   5:   0f b6 56 17             movzbl 0x17(%rsi),%edx
   9:   84 d2                   test   %dl,%dl
   b:   79 07                   jns    14 <std::string::operator=(std::string const&)+0x14>
   d:   48 8b 56 08             mov    0x8(%rsi),%rdx
  11:   48 8b 36                mov    (%rsi),%rsi
  14:   e9 00 00 00 00          jmpq   19 <std::string::operator=(std::string const&)+0x19>
  19:   48 89 f8                mov    %rdi,%rax
  1c:   c3                      retq

Benchmark (pending per https://reviews.llvm.org/D67667)

```
BM_StringAssignStr_Empty_Opaque                     6.23ns ± 0%             5.19ns ± 0%  -16.70%          (p=0.016 n=5+4)
BM_StringAssignStr_Empty_Transparent                5.86ns ± 0%             5.14ns ± 0%  -12.24%          (p=0.008 n=5+5)
BM_StringAssignStr_Small_Opaque                     8.79ns ± 1%             7.69ns ± 0%  -12.53%          (p=0.008 n=5+5)
BM_StringAssignStr_Small_Transparent                9.44ns ± 0%             8.00ns ± 0%  -15.26%          (p=0.008 n=5+5)
BM_StringAssignStr_Large_Opaque                     25.2ns ± 0%             24.3ns ± 0%   -3.50%          (p=0.008 n=5+5)
BM_StringAssignStr_Large_Transparent                23.6ns ± 0%             22.5ns ± 0%   -4.76%          (p=0.008 n=5+5)
BM_StringAssignStr_Huge_Opaque                       319ns ± 5%              317ns ± 5%     ~             (p=0.690 n=5+5)
BM_StringAssignStr_Huge_Transparent                  319ns ± 5%              317ns ± 5%     ~             (p=0.421 n=5+5)
BM_StringAssignAsciiz_Empty_Opaque                  7.41ns ± 0%             7.77ns ± 0%   +4.89%          (p=0.008 n=5+5)
BM_StringAssignAsciiz_Empty_Transparent             7.54ns ± 3%             7.30ns ± 0%   -3.24%          (p=0.008 n=5+5)
BM_StringAssignAsciiz_Small_Opaque                  9.87ns ± 0%            10.24ns ± 1%   +3.76%          (p=0.008 n=5+5)
BM_StringAssignAsciiz_Small_Transparent             10.4ns ± 1%              9.8ns ± 2%   -5.78%          (p=0.008 n=5+5)
BM_StringAssignAsciiz_Large_Opaque                  30.1ns ± 0%             30.1ns ± 0%     ~             (p=0.167 n=5+5)
BM_StringAssignAsciiz_Large_Transparent             27.1ns ± 0%             27.4ns ± 0%   +0.92%          (p=0.016 n=4+5)
BM_StringAssignAsciiz_Huge_Opaque                    383ns ± 4%              382ns ± 4%     ~             (p=0.548 n=5+5)
BM_StringAssignAsciiz_Huge_Transparent               375ns ± 0%              380ns ± 0%   +1.37%          (p=0.029 n=4+4)
BM_StringAssignAsciizMix_Opaque                     14.0ns ± 0%             14.0ns ± 0%     ~             (p=0.881 n=5+5)
BM_StringAssignAsciizMix_Transparent                13.7ns ± 1%             13.8ns ± 0%     ~             (p=0.056 n=5+5)
```

llvm-svn: 374137

[c++20] P1152R4: warn on any simple-assignment to a volatile lvalue
whose value is not ignored.

We don't warn on all the cases that are deprecated: specifically, we
choose to not warn for now if there are parentheses around the
assignment but its value is not actually used. This seems like a more
defensible rule, particularly for cases like sizeof(v = a), where the
parens are part of the operand rather than the sizeof syntax.

llvm-svn: 374135

[c++20] Implement most of P1152R4.

Diagnose some now-deprecated uses of volatile types:
 * as function parameter types and return types
 * as the type of a structured binding declaration
 * as the type of the lvalue operand of an increment / decrement /
   compound assignment operator

This does not implement a check for the deprecation of simple
assignments whose results are used; that check requires somewhat
more complexity and will be addressed separately.

llvm-svn: 374133

Explicitly set entry point arch when it's thumb [Second Try]

Summary:
This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added.

I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb).
The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash.
This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb.

I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code.

I also run the following on the command line with the `app_process32` where I found the issue:
**Before:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32[0x1640]: .long  0xf0004668                ; unknown opcode
```
**After:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32`:
app_process32[0x1640] <+0>: mov    r0, sp
app_process32[0x1642]:      andeq  r0, r0, r0
```

Reviewers: clayborg, labath, wallace, espindola

Reviewed By: labath

Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines

Tags: #lldb

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

llvm-svn: 374132

[cxx_status] Note that Clang has supported std::source_location since
version 9.

llvm-svn: 374131

Factor out some duplication. NFC.

llvm-svn: 374130

gn build: unbreak libcxx build after r374116 by restoring gen_link_script.py for gn

llvm-svn: 374129

[Docs] Fixes broken sphinx build - undefined label

Removes label ref pointing to non-existent subsystem docs page.

llvm-svn: 374128

[clang-scan-deps] Improve string/character literal skipping

The existing string/character literal skipping code in the
dependency directives source minimizer has two issues:

- It doesn't stop the scanning when a newline is reached before the terminating character,
unlike the lexer which considers the token to be done (even if it's invalid) at the end of the line.

- It doesn't support whitespace between '\' and the newline when looking if the '\' is used as a line continuation character.

This commit fixes both issues.

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

llvm-svn: 374127

[IRGen] Emit lifetime markers for temporary struct allocas

When passing arguments using temporary allocas, we need to add the
appropriate lifetime markers so that the stack coloring passes can
re-use the stack space.

This patch keeps track of all the lifetime.start calls emited before the
codegened call, and adds the corresponding lifetime.end calls after the
call.

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

llvm-svn: 374126

[sanitizer] Fix crypt.cpp on Android again

llvm-svn: 374125

[IA] Add tests for a few other edge cases

Test with the last eight bits within the range [7F, FF] and with
lower-case hex letters.

llvm-svn: 374124

[dsymutil] Improve verbose output (NFC)

The verbose output for finding relocations assumed that we'd always dump
the DIE after (which starts with a newline) and therefore didn't include
one itself. However, this isn't always true, leading to garbled output.

This patch adds a newline to the verbose output and adds a line that
says that the DIE is being kept (which isn't obvious otherwise). It also
adds a 0x prefix to the relocations.

llvm-svn: 374123

DebugInfo: Move LLE enum handling to .def to match RLE handling

llvm-svn: 374122

Revert Trust the arange accelerator tables in dSYMs

This reverts r374117 (git commit 6399db2f6fd64fa250093368be40eb5ae3af513b)
while inspecting bot breakage.

llvm-svn: 374121

[libc++] Workaround old versions of CMake that don't understand list(JOIN)

llvm-svn: 374120

Fix crash or wrong code bug if a lifetime-extended temporary contains a
"non-constant" value.

If the constant evaluator evaluates part of a variable initializer,
including the initializer for some lifetime-extended temporary, but
fails to fully evaluate the initializer, it can leave behind wrong
values for temporaries encountered in that initialization. Don't try to
emit those from CodeGen! Instead, look at the values that constant
evaluation produced if (and only if) it actually succeeds and we're
emitting the lifetime-extending declaration's initializer as a constant.

llvm-svn: 374119

[OpenMP] Enable thread affinity on FreeBSD

Reviewers: chandlerc, jlpeyton, jdoerfert, dim

Reviewed-By: dim
Differential Revision: https://reviews.llvm.org/D68580

llvm-svn: 374118

Trust the arange accelerator tables in dSYMs

When ingesting aranges from a dSYM it makes sense to always trust the
contents of the accelerator table since it always comes from
dsymutil. According to Instruments, skipping the decoding of all CU
DIEs to get at the DW_AT_ranges attribute removes ~3.5 seconds from
setting a breakpoint by file/line when debugging clang with a
dSYM. Interestingly on the wall clock the speedup is less noticeable,
but still present.

rdar://problem/56057688

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

llvm-svn: 374117

[libc++] Move the linker script generation step to CMake

Summary:
This allows the linker script generation to query CMake properties
(specifically the dependencies of libc++.so) instead of having to
carry these dependencies around manually in global variables. Notice
the removal of the LIBCXX_INTERFACE_LIBRARIES global variable.

Reviewers: phosek, EricWF

Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits

Tags: #libc

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

llvm-svn: 374116

[sanitizer] Fix crypt.cpp test on Darwin

llvm-svn: 374115

StopInfo/Mach: Delete PPC support

LLDB appears to have at least partial support for PPC, but PPC on Mach
isn't a thing AFAIK.

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

llvm-svn: 374114

[clang] enable_trivial_var_init_zero should not be Joined<>

Reviewers: rnk

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 374113

[CVP} Replace SExt with ZExt if the input is known-non-negative

Summary:
zero-extension is far more friendly for further analysis.
While this doesn't directly help with the shift-by-signext problem, this is not unrelated.

This has the following effect on test-suite (numbers collected after the finish of middle-end module pass manager):
| Statistic                            |     old |     new | delta | percent change |
| correlated-value-propagation.NumSExt |       0 |    6026 |  6026 |   +100.00%     |
| instcount.NumAddInst                 |  272860 |  271283 | -1577 |     -0.58%     |
| instcount.NumAllocaInst              |   27227 |   27226 | -1    |      0.00%     |
| instcount.NumAndInst                 |   63502 |   63320 | -182  |     -0.29%     |
| instcount.NumAShrInst                |   13498 |   13407 | -91   |     -0.67%     |
| instcount.NumAtomicCmpXchgInst       |    1159 |    1159 |  0    |      0.00%     |
| instcount.NumAtomicRMWInst           |    5036 |    5036 |  0    |      0.00%     |
| instcount.NumBitCastInst             |  672482 |  672353 | -129  |     -0.02%     |
| instcount.NumBrInst                  |  702768 |  702195 | -573  |     -0.08%     |
| instcount.NumCallInst                |  518285 |  518205 | -80   |     -0.02%     |
| instcount.NumExtractElementInst      |   18481 |   18482 |  1    |      0.01%     |
| instcount.NumExtractValueInst        |   18290 |   18288 | -2    |     -0.01%     |
| instcount.NumFAddInst                |  139035 |  138963 | -72   |     -0.05%     |
| instcount.NumFCmpInst                |   10358 |   10348 | -10   |     -0.10%     |
| instcount.NumFDivInst                |   30310 |   30302 | -8    |     -0.03%     |
| instcount.NumFenceInst               |     387 |     387 |  0    |      0.00%     |
| instcount.NumFMulInst                |   93873 |   93806 | -67   |     -0.07%     |
| instcount.NumFPExtInst               |    7148 |    7144 | -4    |     -0.06%     |
| instcount.NumFPToSIInst              |    2823 |    2838 |  15   |      0.53%     |
| instcount.NumFPToUIInst              |    1251 |    1251 |  0    |      0.00%     |
| instcount.NumFPTruncInst             |    2195 |    2191 | -4    |     -0.18%     |
| instcount.NumFSubInst                |   92109 |   92103 | -6    |     -0.01%     |
| instcount.NumGetElementPtrInst       | 1221423 | 1219157 | -2266 |     -0.19%     |
| instcount.NumICmpInst                |  479140 |  478929 | -211  |     -0.04%     |
| instcount.NumIndirectBrInst          |       2 |       2 |  0    |      0.00%     |
| instcount.NumInsertElementInst       |   66089 |   66094 |  5    |      0.01%     |
| instcount.NumInsertValueInst         |    2032 |    2030 | -2    |     -0.10%     |
| instcount.NumIntToPtrInst            |   19641 |   19641 |  0    |      0.00%     |
| instcount.NumInvokeInst              |   21789 |   21788 | -1    |      0.00%     |
| instcount.NumLandingPadInst          |   12051 |   12051 |  0    |      0.00%     |
| instcount.NumLoadInst                |  880079 |  878673 | -1406 |     -0.16%     |
| instcount.NumLShrInst                |   25919 |   25921 |  2    |      0.01%     |
| instcount.NumMulInst                 |   42416 |   42417 |  1    |      0.00%     |
| instcount.NumOrInst                  |  100826 |  100576 | -250  |     -0.25%     |
| instcount.NumPHIInst                 |  315118 |  314092 | -1026 |     -0.33%     |
| instcount.NumPtrToIntInst            |   15933 |   15939 |  6    |      0.04%     |
| instcount.NumResumeInst              |    2156 |    2156 |  0    |      0.00%     |
| instcount.NumRetInst                 |   84485 |   84484 | -1    |      0.00%     |
| instcount.NumSDivInst                |    8599 |    8597 | -2    |     -0.02%     |
| instcount.NumSelectInst              |   45577 |   45913 |  336  |      0.74%     |
| instcount.NumSExtInst                |   84026 |   78278 | -5748 |     -6.84%     |
| instcount.NumShlInst                 |   39796 |   39726 | -70   |     -0.18%     |
| instcount.NumShuffleVectorInst       |  100272 |  100292 |  20   |      0.02%     |
| instcount.NumSIToFPInst              |   29131 |   29113 | -18   |     -0.06%     |
| instcount.NumSRemInst                |    1543 |    1543 |  0    |      0.00%     |
| instcount.NumStoreInst               |  805394 |  804351 | -1043 |     -0.13%     |
| instcount.NumSubInst                 |   61337 |   61414 |  77   |      0.13%     |
| instcount.NumSwitchInst              |    8527 |    8524 | -3    |     -0.04%     |
| instcount.NumTruncInst               |   60523 |   60484 | -39   |     -0.06%     |
| instcount.NumUDivInst                |    2381 |    2381 |  0    |      0.00%     |
| instcount.NumUIToFPInst              |    5549 |    5549 |  0    |      0.00%     |
| instcount.NumUnreachableInst         |    9855 |    9855 |  0    |      0.00%     |
| instcount.NumURemInst                |    1305 |    1305 |  0    |      0.00%     |
| instcount.NumXorInst                 |   10230 |   10081 | -149  |     -1.46%     |
| instcount.NumZExtInst                |   60353 |   66840 |  6487 |     10.75%     |
| instcount.TotalBlocks                |  829582 |  829004 | -578  |     -0.07%     |
| instcount.TotalFuncs                 |   83818 |   83817 | -1    |      0.00%     |
| instcount.TotalInsts                 | 7316574 | 7308483 | -8091 |     -0.11%     |

TLDR: we produce -0.11% less instructions, -6.84% less `sext`, +10.75% more `zext`.
To be noted, clearly, not all new `zext`'s are produced by this fold.

(And now i guess it might have been interesting to measure this for D68103 :S)

Reviewers: nikic, spatel, reames, dberlin

Reviewed By: nikic

Subscribers: hiraditya, jfb, llvm-commits

Tags: #llvm

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

llvm-svn: 374112

[CVP][NFC] Revisit sext vs. zext test

llvm-svn: 374111

[clang] Add llvm-ifs in test deps

llvm-svn: 374110

Fix `compiler_rt_logbf_test.c` test failure for Builtins-i386-darwin test suite.

Summary:
It seems that compiler-rt's implementation and Darwin
libm's implementation of `logbf()` differ when given a NaN
with raised sign bit. Strangely this behaviour only happens with
i386 Darwin libm. For x86_64 and x86_64h the existing compiler-rt
implementation matched Darwin libm.

To workaround this the `compiler_rt_logbf_test.c` has been modified
to do a comparison on the `fp_t` type and if that fails check if both
values are NaN. If both values are NaN they are equivalent and no
error needs to be raised.

rdar://problem/55565503

Reviewers: rupprecht, scanon, compnerd, echristo
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D67999

llvm-svn: 374109

Add test coverage to printing of enums and fix display of unsigned values

TestCPP11EnumTypes.py should have covered all our bases when it comes
to typed enums, but it missed the regression introduced in r374066.
The reason it didn't catch it is somewhat funny: the test was copied
over from another test that recompiled a source file with a different
base type every time, but neither the test source nor the python code
was adapted for testing enums. As a result, this test was just running
8 times the exact same checks on the exact same binary.

This commit fixes the coverage and addresses the issue revealed by
the new tests.

llvm-svn: 374108

[OPENMP50]Multiple vendors in vendor context must be treated as logical
and of vendors, not or.

If several vendors are provided in the same vendor context trait, the
context shall match only if all vendors are matching, not one of them.
This is per OpenMP 5.0, 2.3.3 Matching and Scoring Context Selectors,
all selectors in the construct, device, and implementation sets of the
context selector appear in the corresponding trait set of the OpenMP
context.

llvm-svn: 374107

StopInfo/Mach: Use early-exits, reflow messy comments, NFCI

llvm-svn: 374106

Try to get ubsan-blacklist-vfs.c pass more on Windows

llvm-svn: 374105

[Reproducer] Don't isntrument methods that get called from the signal handler.

LLDB's signal handlers call SBDebugger methods, which themselves try to
be really careful about not doing anything non-signal safe. The
Reproducer record macro is not careful though, and does unsafe things
which potentially caused LLDB to crash. Given that these methods are not
particularly interesting I've swapped the RECORD macros with DUMMY ones,
so that we still register the API boundary but don't do anything
non-signal safe.

Thanks Jim for figuring this one out!

llvm-svn: 374104

Try to get readability-deleted-default.cpp to pass on Windows.

In MS compatibility mode, "extern inline void g()" is not a redundant
declaration for "inline void g()", because of redeclForcesDefMSVC()
(see PR19264, r205485).

To fix, run the test with -fms-compatiblity forced on and off
and explicit check for the differing behavior for extern inline.

Final bit of PR43593.

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

llvm-svn: 374103

Mark several PointerIntPair methods as lvalue-only

No point in mutating 'this' if it's just going to be thrown away.

https://reviews.llvm.org/D63945

llvm-svn: 374102

[tblgen] Add getOperatorAsDef() to Record

Summary:
While working with DagInit's, it's often the case that you expect the
operator to be a reference to a def. This patch adds a wrapper for this
common case to reduce the amount of boilerplate callers need to duplicate
repeatedly.

getOperatorAsDef() returns the record if the DagInit has an operator that is
a DefInit. Otherwise, it prints a fatal error.

There's only a few pre-existing examples in LLVM at the moment and I've
left a few instances of the code this simplifies as they had more specific
error messages than the generic one this produces. I'm going to be using
this a fair bit in my subsequent patches.

Reviewers: bogner, volkan, nhaehnle

Reviewed By: nhaehnle

Subscribers: nhaehnle, hiraditya, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, lenary, s.egerton, pzheng, llvm-commits

Tags: #llvm

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

llvm-svn: 374101

[CMake] Fix building without python on Windows

Summary: find_python_libs_windows might set LLDB_DISABLE_PYTHON to ON.
Unfortunately we do not re-check this variable before using variables filled in
by find_python_libs_windows, leading to a failed configuration.

llvm-svn: 374100

[BPF] do compile-once run-everywhere relocation for bitfields

A bpf specific clang intrinsic is introduced:
   u32 __builtin_preserve_field_info(member_access, info_kind)
Depending on info_kind, different information will
be returned to the program. A relocation is also
recorded for this builtin so that bpf loader can
patch the instruction on the target host.
This clang intrinsic is used to get certain information
to facilitate struct/union member relocations.

The offset relocation is extended by 4 bytes to
include relocation kind.
Currently supported relocation kinds are
 enum {
    FIELD_BYTE_OFFSET = 0,
    FIELD_BYTE_SIZE,
    FIELD_EXISTENCE,
    FIELD_SIGNEDNESS,
    FIELD_LSHIFT_U64,
    FIELD_RSHIFT_U64,
 };
for __builtin_preserve_field_info. The old
access offset relocation is covered by
    FIELD_BYTE_OFFSET = 0.

An example:
struct s {
    int a;
    int b1:9;
    int b2:4;
};
enum {
    FIELD_BYTE_OFFSET = 0,
    FIELD_BYTE_SIZE,
    FIELD_EXISTENCE,
    FIELD_SIGNEDNESS,
    FIELD_LSHIFT_U64,
    FIELD_RSHIFT_U64,
};

void bpf_probe_read(void *, unsigned, const void *);
int field_read(struct s *arg) {
  unsigned long long ull = 0;
  unsigned offset = __builtin_preserve_field_info(arg->b2, FIELD_BYTE_OFFSET);
  unsigned size = __builtin_preserve_field_info(arg->b2, FIELD_BYTE_SIZE);
 #ifdef USE_PROBE_READ
  bpf_probe_read(&ull, size, (const void *)arg + offset);
  unsigned lshift = __builtin_preserve_field_info(arg->b2, FIELD_LSHIFT_U64);
 #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
  lshift = lshift + (size << 3) - 64;
 #endif
 #else
  switch(size) {
  case 1:
    ull = *(unsigned char *)((void *)arg + offset); break;
  case 2:
    ull = *(unsigned short *)((void *)arg + offset); break;
  case 4:
    ull = *(unsigned int *)((void *)arg + offset); break;
  case 8:
    ull = *(unsigned long long *)((void *)arg + offset); break;
  }
  unsigned lshift = __builtin_preserve_field_info(arg->b2, FIELD_LSHIFT_U64);
 #endif
  ull <<= lshift;
  if (__builtin_preserve_field_info(arg->b2, FIELD_SIGNEDNESS))
    return (long long)ull >> __builtin_preserve_field_info(arg->b2, FIELD_RSHIFT_U64);
  return ull >> __builtin_preserve_field_info(arg->b2, FIELD_RSHIFT_U64);
}

There is a minor overhead for bpf_probe_read() on big endian.

The code and relocation generated for field_read where bpf_probe_read() is
used to access argument data on little endian mode:
        r3 = r1
        r1 = 0
        r1 = 4  <=== relocation (FIELD_BYTE_OFFSET)
        r3 += r1
        r1 = r10
        r1 += -8
        r2 = 4  <=== relocation (FIELD_BYTE_SIZE)
        call bpf_probe_read
        r2 = 51 <=== relocation (FIELD_LSHIFT_U64)
        r1 = *(u64 *)(r10 - 8)
        r1 <<= r2
        r2 = 60 <=== relocation (FIELD_RSHIFT_U64)
        r0 = r1
        r0 >>= r2
        r3 = 1  <=== relocation (FIELD_SIGNEDNESS)
        if r3 == 0 goto LBB0_2
        r1 s>>= r2
        r0 = r1
LBB0_2:
        exit

Compare to the above code between relocations FIELD_LSHIFT_U64 and
FIELD_LSHIFT_U64, the code with big endian mode has four more
instructions.
        r1 = 41   <=== relocation (FIELD_LSHIFT_U64)
        r6 += r1
        r6 += -64
        r6 <<= 32
        r6 >>= 32
        r1 = *(u64 *)(r10 - 8)
        r1 <<= r6
        r2 = 60   <=== relocation (FIELD_RSHIFT_U64)

The code and relocation generated when using direct load.
        r2 = 0
        r3 = 4
        r4 = 4
        if r4 s> 3 goto LBB0_3
        if r4 == 1 goto LBB0_5
        if r4 == 2 goto LBB0_6
        goto LBB0_9
LBB0_6:                                 # %sw.bb1
        r1 += r3
        r2 = *(u16 *)(r1 + 0)
        goto LBB0_9
LBB0_3:                                 # %entry
        if r4 == 4 goto LBB0_7
        if r4 == 8 goto LBB0_8
        goto LBB0_9
LBB0_8:                                 # %sw.bb9
        r1 += r3
        r2 = *(u64 *)(r1 + 0)
        goto LBB0_9
LBB0_5:                                 # %sw.bb
        r1 += r3
        r2 = *(u8 *)(r1 + 0)
        goto LBB0_9
LBB0_7:                                 # %sw.bb5
        r1 += r3
        r2 = *(u32 *)(r1 + 0)
LBB0_9:                                 # %sw.epilog
        r1 = 51
        r2 <<= r1
        r1 = 60
        r0 = r2
        r0 >>= r1
        r3 = 1
        if r3 == 0 goto LBB0_11
        r2 s>>= r1
        r0 = r2
LBB0_11:                                # %sw.epilog
        exit

Considering verifier is able to do limited constant
propogation following branches. The following is the
code actually traversed.
        r2 = 0
        r3 = 4   <=== relocation
        r4 = 4   <=== relocation
        if r4 s> 3 goto LBB0_3
LBB0_3:                                 # %entry
        if r4 == 4 goto LBB0_7
LBB0_7:                                 # %sw.bb5
        r1 += r3
        r2 = *(u32 *)(r1 + 0)
LBB0_9:                                 # %sw.epilog
        r1 = 51   <=== relocation
        r2 <<= r1
        r1 = 60   <=== relocation
        r0 = r2
        r0 >>= r1
        r3 = 1
        if r3 == 0 goto LBB0_11
        r2 s>>= r1
        r0 = r2
LBB0_11:                                # %sw.epilog
        exit

For native load case, the load size is calculated to be the
same as the size of load width LLVM otherwise used to load
the value which is then used to extract the bitfield value.

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

llvm-svn: 374099

[NFC] Attempt to make ubsan-blacklist-vfs test pass on Windows

Previously disabled in d0c2d5daa3e

llvm-svn: 374098

[driver][hip] Skip bundler if host action is nothing.

Reviewers: sfantao, tra, yaxunl

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 374097

Reflow/fix doxygen comments.

llvm-svn: 374096

Fix sign extension handling in DumpEnumValue

When an enumerator has an unsigned type and its high bit set, the
code introduced in r374067 would fail to match it due to a sign
extension snafu. This commit fixes this aspec of the code and should
fix the bots.

I think it's not a complete fix though, I'll add more test coverage
and additional tweaks in a follow-up commit.

llvm-svn: 374095

exception handling in PythonDataObjects.

Summary:
Python APIs nearly all can return an exception.   They do this
by returning NULL, or -1, or some such value and setting
the exception state with PyErr_Set*().   Exceptions must be
handled before further python API functions are called.   Failure
to do so will result in asserts on debug builds of python.
It will also sometimes, but not usually result in crashes of
release builds.

Nearly everything in PythonDataObjects.h needs to be updated
to account for this.   This patch doesn't fix everything,
but it does introduce some new methods using Expected<>
return types that are safe to use.

split off from https://reviews.llvm.org/D68188

Reviewers: JDevlieghere, jasonmolenda, labath, zturner

Reviewed By: labath

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 374094

[OPENMP50]Do not allow multiple same context traits in the same context
selector.

According to OpenMP 5.0, 2.3.2 Context Selectors, Restrictions, each
trait-selector-name can only be specified once. Added check for this
restriction.

llvm-svn: 374093

AMDGPU: Fix i16 arithmetic pattern redundancy

There were 2 problems here. First, these patterns were duplicated to
handle the inverted shift operands instead of using the commuted
PatFrags.

Second, the point of the zext folding patterns don't apply to the
non-0ing high subtargets. They should be skipped instead of inserting
the extension. The zeroing high code would be emitted when necessary
anyway. This was also emitting unnecessary zexts in cases where the
high bits were undefined.

llvm-svn: 374092

Revert "[LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize"

Also Revert "[LoopVectorize] Fix non-debug builds after rL374017"

This reverts commit 9f41deccc0e648a006c9f38e11919f181b6c7e0a.
This reverts commit 18b6fe07bcf44294f200bd2b526cb737ed275c04.

The patch is breaking PowerPC internal build, checked with author, reverting
on behalf of him for now due to timezone.

llvm-svn: 374091

[SLP] add test with prefer-vector-width function attribute; NFC (PR43578)

llvm-svn: 374090

[CodeExtractor] Factor out and reuse shrinkwrap analysis

Factor out CodeExtractor's analysis of allocas (for shrinkwrapping
purposes), and allow the analysis to be reused.

This resolves a quadratic compile-time bug observed when compiling
AMDGPUDisassembler.cpp.o.

Pre-patch (Release + LTO clang):

```
   ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
  176.5278 ( 57.8%)   0.4915 ( 18.5%)  177.0192 ( 57.4%)  177.4112 ( 57.3%)  Hot Cold Splitting
```

Post-patch (ReleaseAsserts clang):

```
   ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
  1.4051 (  3.3%)   0.0079 (  0.3%)   1.4129 (  3.2%)   1.4129 (  3.2%)  Hot Cold Splitting
```

Testing: check-llvm, and comparing the AMDGPUDisassembler.cpp.o binary
pre- vs. post-patch.

An alternate approach is to hide CodeExtractorAnalysisCache from clients
of CodeExtractor, and to recompute the analysis from scratch inside of
CodeExtractor::extractCodeRegion(). This eliminates some redundant work
in the shrinkwrapping legality check. However, some clients continue to
exhibit O(n^2) compile time behavior as computing the analysis is O(n).

rdar://55912966

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

llvm-svn: 374089

[sanitizer] Disable crypt*.cpp tests on Android

llvm-svn: 374088

AMDGPU: Add offsets to MMO when lowering buffer intrinsics

Summary:
Without offsets on the MachineMemOperands (MMOs),
MachineInstr::mayAlias() will return true for all reads and writes to the
same resource descriptor.  This leads to O(N^2) complexity in the MachineScheduler
when analyzing dependencies of buffer loads and stores.  It also limits
the SILoadStoreOptimizer from merging more instructions.

This patch reduces the compile time of one pathological compute shader
from 12 seconds to 1 second.

Reviewers: arsenm, nhaehnle

Reviewed By: arsenm

Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, hiraditya, jfb, llvm-commits

Tags: #llvm

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

llvm-svn: 374087

[Attributor][Fix] Temporary fix for windows build bot failure

D65402 causes test failure related to attributor-max-iterations.
This commit removes attributor-max-iterations-verify for now.
I'll examine the factor and the flag should be reverted.

llvm-svn: 374086

CodeGenPrepare - silence static analyzer dyn_cast<> null dereference warnings. NFCI.

The static analyzer is warning about potential null dereferences, but in these cases we should be able to use cast<> directly and if not assert will fire for us.

llvm-svn: 374085

ObjectFileMachO: Replace std::map with llvm::DenseMap (NFC)

This makes parsing the symbol table of clang marginally faster. (Hashtable versus tree).

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

llvm-svn: 374084

[AMDGPU] Disable unused gfx10 dpp instructions

Inhibit generation of unused real dpp instructions on gfx10 just
like it is done on other subtargets. This does not change anything
because these are illegal anyway and not accepted, but it does
reduce the number of instruction definitions generated.

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

llvm-svn: 374083

Replace regex match with rfind (NFCish)

This change is mostly performance-neutral since our regex engine is
fast, but it's IMHO slightly more readable.  Also, matching matching
parenthesis is not a great match for regular expressions.

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

llvm-svn: 374082

Replace static const StringRef with StringRef (NFC)

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

llvm-svn: 374081

Remove constructor and unused method (NFC).

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

llvm-svn: 374080

[libc++] Make sure we link all system libraries into the benchmarks

It turns out that r374056 broke _some_ build bots again, specifically
the ones using sanitizers. Instead of trying to link the right system
libraries to the benchmarks bit-by-bit, let's just link exactly the
system libraries that libc++ itself needs.

llvm-svn: 374079

[UpdateCCTestChecks] Detect function mangled name on separate line

Sometimes functions with large comment blocks in front of them have their
declarations output on several lines by c-index-test.  Hence the one-line
function name/line/mangled pattern will not work to detect them.  Break the
pattern up into two patterns and keep state after seeing the name/line
information until we finally see the mangled name.

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

llvm-svn: 374078

Revert "[platform process list] add a flag for showing the processes of all users"

This reverts commit 080f35fb875f52c924ee37ed4d56a51fe7056afa.

 Conflicts:
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestPlatformClient.py

llvm-svn: 374077

[Testsuite] Get rid of most of the recursive shared library Makefiles

Most of the secondary Makefiles we have are just a couple variable
definitions and then an include of Makefile.rules. This patch removes
most of the secondary Makefiles and replaces them with a direct
invocation of Makefile.rules in the main Makefile. The specificities
of each sub-build are listed right there on the recursive $(MAKE)
call. All the variables that matter are being passed automagically by
make as they have been passed on the command line. The only things you
need to specify are the variables customizating the Makefile.rules
logic for each image.

This patch also removes most of the clean logic from those Makefiles
and from Makefile.rules. The clean rule is not required anymore now
that we run the testsuite in a separate build directory that is wiped
with each run. The patch leaves a very crude version of clean in
Makefile.rules which removes everything inside of $(BUILDDIR). It does
this only when the $(BUILDDIR) looks like a sub-directory of our
standard testsuite build directory to be extra safe.

Reviewers: aprantl, labath

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 374076

[NFC][CVP] Add tests where we can replace sext with zext

If the sign bit of the value that is being sign-extended is not set,
i.e. the value is non-negative (s>= 0), then zero-extension will suffice,
and is better for analysis: https://rise4fun.com/Alive/a8PD

llvm-svn: 374075

(Re)generate various tests. NFC

llvm-svn: 374074

[WebAssembly] Fix a bug in 'try' placement

Summary:
When searching for local expression tree created by stackified
registers, for 'block' placement, we start the search from the previous
instruction of a BB's terminator. But in 'try''s case, we should start
from the previous instruction of a call that can throw, or a EH_LABEL
that precedes the call, because the return values of the call's previous
instructions can be stackified and consumed by the throwing call.

For example,
```
  i32.call @foo
  call @bar         ; may throw
  br $label0
```
In this case, if we start the search from the previous instruction of
the terminator (`br` here), we end up stopping at `call @bar` and place
a 'try' between `i32.call @foo` and `call @bar`, because `call @bar`
does not have a return value so it is not a local expression tree of
`br`.

But in this case, unlike when placing 'block's, we should start the
search from `call @bar`, because the return value of `i32.call @foo` is
stackified and used by `call @bar`.

Reviewers: dschuff

Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits

Tags: #llvm

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

llvm-svn: 374073

[OPENMP50]Prohibit multiple context selector sets in context selectors.

According to OpenMP 5.0, 2.3.2 Context Selectors, Restrictions, each
trait-set-selector-name can only be specified once. Added check to
implement this restriction.

llvm-svn: 374072

[lldb] Avoid resource leak

Summary:
Before the pointer variable `args_dict` was assigned the result of an
allocation with `new` and then `args_dict` is passed to
`GetValueForKeyAsDictionary` which immediatly and unconditionally
assigns `args_dict` to `nullptr`:

```
    bool GetValueForKeyAsDictionary(llvm::StringRef key,
                                    Dictionary *&result) const {
      result = nullptr;
```

This caused a memory leak which was found in my coverity scan instance
under CID 224753: https://scan.coverity.com/projects/kwk-llvm-project.

Reviewers: jankratochvil, teemperor

Reviewed By: teemperor

Subscribers: teemperor, lldb-commits

Tags: #lldb

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

llvm-svn: 374071

[builtins] Unbreak build on FreeBSD armv7 after D60351

headers include reordering.

Reviewers: phosek, echristo

Reviewed-By: phosek
Differential Revsion: https://reviews.llvm.org/D68045

llvm-svn: 374070