compiler-rt: Rename .cc file in lib/sanitizer_common/tests to .cpp

See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran

  for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $(basename $f) . ; done

and manually updated references to renamed files found by that.

llvm-svn: 367467

[X86] Add test cases to show premature decomposition of vector multiplies into shift+add/sub for types that aren't legal and need to be split. NFC

llvm-svn: 367466

[X86] Add AVX512DQ command lines to vector-mul.ll to show that we use vpmullq instead of shift+add/sub for some cases. NFC

llvm-svn: 367465

gn build: Merge r367463

llvm-svn: 367464

compiler-rt: Rename .cc file in lib/sanitizer_common to .cpp

See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran

  for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done

and manually updated (many) references to renamed files found by that.

llvm-svn: 367463

Attempt to heal bots after r367456

llvm-svn: 367462

[SCCP] Update condition to avoid overflow.

Summary:
Update condition to remove addition that may cause an overflow.
Resolves PR42814.

Reviewers: sanjoy, RKSimon

Subscribers: jlebar, llvm-commits

Tags: #llvm

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

llvm-svn: 367461

compiler-rt: Rename .cc file in lib/profile to .cpp

See https://reviews.llvm.org/D58620 for discussion.

Note how the comment in the file already said ".cpp" :)

llvm-svn: 367460

[CommandCompletions] Remove commented out code.

We use version control here.

llvm-svn: 367459

[docs] Add references to unreferenced footnotes.

Thanks to Stefan Granitz for catching the issue.

llvm-svn: 367458

gn build: Merge r367456

llvm-svn: 367457

compiler-rt: Rename .cc files in lib/interception to .cpp.

See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran

  for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done

and manually updated references to renamed files found by that.

llvm-svn: 367456

Fix completion for functions in anonymous namespaces

I was going through some of the old bugs and came across PR21069 which I
was able to reproduce. The issue is that we match the regex `^foo`
against the `DW_AT_name` in the DWARF, which for our anonymous function
is indeed `foo`. However, when we get the function name from the symbol
context, the result is `(anonymous namespace)::foo()`. This throws off
completions, which assumes that it's appending to whatever is already
present on the input, resulting in a bogus
`b fooonymous\ namespace)::foo()`.

Bug report: https://llvm.org/PR21069

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

llvm-svn: 367455

gn build: Merge r367452 and add standalone sources

llvm-svn: 367454

[clangd] Ignore semicolons, whitespace, and comments in SelectionTree.

Summary:
Whitespace and comments are a clear bugfix: selecting some
comments/space near a statement doesn't mean you're selecting the
surrounding block.

Semicolons are less obvious, but for similar reasons: these tokens
aren't actually claimed by any AST node (usually), so an AST-based model
like SelectionTree shouldn't take them into account.

Callers may still sometimes care about semis of course:
 - when the selection is an expr with a non-expr parent, selection of
   the semicolon indicates intent to select the statement.
 - when a statement with a trailing semi is selected, we need to know
   its range to ensure it can be removed.
SelectionTree may or may not play a role here, but these are separate questions
from its core function of describing which AST nodes were selected.

The mechanism here is the TokenBuffer from syntax-trees. We use it in a
fairly low-level way (just to get boundaries of raw spelled tokens). The
actual mapping of AST nodes to coordinates continues to use the (fairly
mature) SourceLocation based logic. TokenBuffer/Syntax trees
don't currently offer an alternative to getFileRange(), I think.

Reviewers: SureYeaah, kadircet

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

Tags: #clang

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

llvm-svn: 367453

compiler-rt: Rename .cc files in lib/ubsan to .cpp.

See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran

  for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done

and manually updated references to renamed files found by that.

llvm-svn: 367452

[MemorySSA] Add additional verification for phis.

Summary:
Verify that the incoming defs into phis are the last defs from the
respective incoming blocks.
When moving blocks, insertDef must RenameUses. Adding this verification
makes GVNHoist tests fail that uncovered this issue.

Reviewers: george.burgess.iv

Subscribers: jlebar, Prazek, llvm-commits

Tags: #llvm

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

llvm-svn: 367451

gn build: Add build files for compiler-rt/lib/profile

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

llvm-svn: 367450

gn build: Make builtin library build on macOS

For now, it only builds the x86_64 slice.

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

llvm-svn: 367449

gn build: Fix redundant object files in builtin lib.

compiler-rt's builtin library has generic implementations of many
functions, and then per-arch optimized implementations of some.

In the CMake build, both filter_builtin_sources() and an explicit loop
at the end of the build file (see D37166) filter out the generic
versions if a per-arch file is present.

The GN build wasn't doing this filtering. Just do the filtering manually
and explicitly, instead of being clever.

While here, also remove files from the mingw/arm build that are
redundantly listed after D39938 / r318139 (both from the CMake and the
GN build).

While here, also fix a target_os -> target_cpu typo.

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

llvm-svn: 367448

[InstCombine] canonicalize fneg before fmul/fdiv

Reverse the canonicalization of fneg relative to fmul/fdiv. That makes it
easier to implement the transforms (and possibly other fneg transforms) in
1 place because we can always start the pattern match from fneg (either the
legacy binop or the new unop).

There's a secondary practical benefit seen in PR21914 and PR42681:
https://bugs.llvm.org/show_bug.cgi?id=21914
https://bugs.llvm.org/show_bug.cgi?id=42681
...hoisting fneg rather than sinking seems to play nicer with LICM in IR
(although this change may expose analysis holes in the other direction).

1. The instcombine test changes show the expected neutral IR diffs from
   reversing the order.

2. The reassociation tests show that we were missing an optimization
   opportunity to fold away fneg-of-fneg. My reading of IEEE-754 says
   that all of these transforms are allowed (regardless of binop/unop
   fneg version) because:

   "For all other operations [besides copy/abs/negate/copysign], this
   standard does not specify the sign bit of a NaN result."
   In all of these transforms, we always have some other binop
   (fadd/fsub/fmul/fdiv), so we are free to flip the sign bit of a
   potential intermediate NaN operand.
   (If that interpretation is wrong, then we must already have a bug in
   the existing transforms?)

3. The clang tests shouldn't exist as-is, but that's effectively a
   revert of rL367149 (the test broke with an extension of the
   pre-existing fneg canonicalization in rL367146).

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

llvm-svn: 367447

Reland "[DwarfDebug] Dump call site debug info"

The build failure found after the rL365467 has been
resolved.

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

llvm-svn: 367446

[docs][FIX] Add missing word to documentation in terms of SCCs

In the approval of D65299, commited as rL367440, I mentioned that my
proposed wording was lacking the word "maximal". It is added now for
correctness.

llvm-svn: 367445

[build] Add the ability to create a symlink for lipo

Add user enabled option to create lipo with symlink to llvm-lipo
Used rL326381 for reference.

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

llvm-svn: 367444

[AMDGPU] Fix for vectorizer crash with pointers of different size

When vectorizer strips pointers it can eventually end up with
pointers of two different sizes, then SCEV will crash.

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

llvm-svn: 367443

[Sanitizer][ASAN][MSAN] Fix infinite recursion on FreeBSD

Summary:
MSAN was broken on FreeBSD by https://reviews.llvm.org/D55703: after this
change accesses to the key variable call __tls_get_addr, which is
intercepted. The interceptor then calls GetCurrentThread which calls
MsanTSDGet which again calls __tls_get_addr, etc...
Using the default implementation in the SANITIZER_FREEBSD case fixes MSAN
for me.

I then applied the same change to ASAN (introduced in https://reviews.llvm.org/D55596)
but that did not work yet. In the ASAN case, we get infinite recursion
again during initialization, this time because calling pthread_key_create() early on
results in infinite recursion. pthread_key_create() calls sysctlbyname()
which is intercepted but COMMON_INTERCEPTOR_NOTHING_IS_INITIALIZED returns
true, so the interceptor calls internal_sysctlbyname() which then ends up
calling the interceptor again. I fixed this issue by using dlsym() to get
the libc version of sysctlbyname() instead.

This fixes https://llvm.org/PR40761

Reviewers: vitalybuka, krytarowski, devnexen, dim, bsdjhb, #sanitizers, MaskRay

Reviewed By: MaskRay

Subscribers: MaskRay, emaste, kubamracek, jfb, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

llvm-svn: 367442

Don't crash when pass by value struct has no definition.

llvm-svn: 367441

[docs] Reword documentation in terms of SCCs not cycles

Given the example:
header:
  br i1 %c, label %next, label %header
next:
  br i1 %c2, label %exit, label %header

We end up with a loop containing both header and next.  Given that, the describing the loop in terms of cycles is confusing since we have multiple distinct cycles within a single Loop.  Standardize on the SCC to clarify.

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

llvm-svn: 367440

[NFC][InstCombine] Add xor-or-icmp tests with icmp having extra uses

Currently InstCombiner::foldXorOfICmps() bailouts if the
ICMP it wants to invert has extra uses. As it can be seen
in the tests in previous commit, this is super unfortunate,
this is the single pattern that is left non-canonicalized.

We could analyze if we can also invert all the uses if said ICMP
at the same time, thus not bailing out there.
I'm not seeing any nicer alternative.

llvm-svn: 367439

[NFC][InstCombine] Add baseline tests with non-canonical CLAMP pattern

As disscussed in https://reviews.llvm.org/D65148#1603922
these would all need to be canonicalized to traditional clamp pattern.

llvm-svn: 367438

[AARCH64] Switch relocations R_AARCH64_TLS_TPREL64 and R_AARCH64_DTPMOD64

The ELF for the Arm 64-bit Architecture document originally specified
R_AARCH64_TLS_DTPREL64 = 0x404
R_AARCH64_TLS_DTPMOD64 = 0x405

LLVM correctly followed the document. Unfortunately in binutils these
two codes were reversed:
R_AARCH64_TLS_DTPMOD64 = 0x404
R_AARCH64_TLS_DTPREL64 = 0x405
Given that binaries had shipped this change has become the defacto standard
interpretation of these relocation codes for any toolchain that wanted to
remain compatible with GNU.

To recognize this the latest version of the ABI document has renamed
the relocations to R_AARCH64_TLS_IMPDEF1 and R_AARCH64_TLS_IMPDEF2
permitting a toolchain to choose between the two relocation types, and
recommending that toolchains follow the GNU interpretation for maximum
compatibility.

Given that upstream llvm has never implemented the standard TLS model for
AArch64 so we have no binary legacy, synchronize with GCC so that we don't
create incompatible objects in the future. So far the only visible change
is in llvm-readobj as it can decode these relocations. Tthis change will
mean that llvm-readobj decodes the same way as GNU readelf.

fixes PR40507

llvm-svn: 367437

[X86] Moved IsNOT helper earlier. NFCI.

Makes it available for more combines to use without adding declarations.

llvm-svn: 367436

[X86][SSE] Add test cases for PR42825

llvm-svn: 367435

[ARM] Reject CSEL instructions with invalid operands

Summary:
According to the Armv8.1-M manual CSEL, CSINC, CSINV and CSNEG are
"constrained unpredictable" when SP is used as the source register Rn.

The assembler should diagnose this case.

Reviewers: momchil.velikov, dmgreen, ostannard, simon_tatham, t.p.northover

Reviewed By: ostannard

Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367433

AMDGPU: Add missing builtin declarations

llvm-svn: 367431

[IPSCCP] Move callsite check to the beginning of the loop.

We have some code marks instructions with struct operands as overdefined,
but if the instruction is a call to a function with tracked arguments,
this breaks the assumption that the lattice values of all call sites
are not overdefined and will be replaced by a constant.

This also re-adds the assertion from D65222, with additionally skipping
non-callsite uses. This patch should address the cases reported in which
the assertion fired.

Fixes PR42738.

Reviewers: efriedma, davide

Reviewed By: efriedma

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

llvm-svn: 367430

[X86][AVX] Ensure chained subvector insertions are the same size (PR42833)

Before combining insert_subvector(insert_subvector(vec, sub0, c0), sub1, c1) patterns, ensure that the subvectors are all the same type. On AVX512 targets especially we might have a mixture of 128/256 subvector insertions.

llvm-svn: 367429

[AArch64] Add support for Transactional Memory Extension (TME)

Re-commit r366322 after some fixes

TME is a future architecture technology, documented in

  https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools
  https://developer.arm.com/docs/ddi0601/a

More about the future architectures:

  https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture

This patch adds support for the TME instructions TSTART, TTEST, TCOMMIT, and
TCANCEL and the target feature/arch extension "tme".

It also implements TME builtin functions, defined in ACLE Q2 2019
(https://developer.arm.com/docs/101028/latest)

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

Patch by Javed Absar and Momchil Velikov

llvm-svn: 367428

[LLVM] Fix Alignment death tests in Release Mode

llvm-svn: 367427

[X86] Regenerate lrshrink test checks to make D65354 diff easier

llvm-svn: 367426

[X86] Regenerate callee-saved test checks to make D65354 diff easier

llvm-svn: 367425

[X86] Regenerate alias-static-alloca test checks to make D65354 diff easier

I've manually added the stack offsets back as these are worth keeping - we really need a way for update_llc_test_checks.py not to mask out useful address math

llvm-svn: 367424

[DivRemPairs] Fixup DNDEBUG build - variable is only used in assertion

llvm-svn: 367423

gn build: Merge r367393

llvm-svn: 367422

[X86] Regenerate vp2intersect tests

Enable nounwind to remove unnecessary stack manipulation code

llvm-svn: 367421

[lldb][NFC] Check in completion crash test case

llvm-svn: 367420

[DivRemPairs] Recommit: Handling for expanded-form rem - recomposition (PR42673)

Summary:
While `-div-rem-pairs` pass can decompose rem in div+rem pair when div-rem pair
is unsupported by target, nothing performs the opposite fold.
We can't do that in InstCombine or DAGCombine since neither of those has access to TTI.
So it makes most sense to teach `-div-rem-pairs` about it.

If we matched rem in expanded form, we know we will be able to place div-rem pair
next to each other so we won't regress the situation.
Also, we shouldn't decompose rem if we matched already-decomposed form.
This is surprisingly straight-forward otherwise.

The original patch was committed in rL367288 but was reverted in rL367289
because it exposed pre-existing RAUW issues in internal data structures
of the pass; those now have been addressed in a previous patch.

https://bugs.llvm.org/show_bug.cgi?id=42673

Reviewers: spatel, RKSimon, efriedma, ZaMaZaN4iK, bogner

Reviewed By: bogner

Subscribers: bogner, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367419

Fix issues with inferior stdout coming out of order

Summary:
We've had a bug where two pieces of code, executing on two threads were
attempting to write inferior output simultaneously. The first one was in
Debugger::HandleProcessEvent, which handled the cases where stdout was
coming while the process was running. The second was in
CommandInterpreter::IOHandlerInputComplete, which was ensuring that any
output is printed before the command which caused process to run
terminates.

Both of these things make sense, but the fact they were implemented as
two independent functions without any synchronization meant that race
conditions could occur (e.g. both threads call process->GetSTDOUT, get
two chunks of data, but then end up calling stream->Write in opposite
order). This was most apparent in situations where a process quickly
writes a bunch of output and then exits (as all our register tests do).

This patch adds a mutex to ensure that stdout forwarding happens
atomically. It also refactors a code somewhat in order to reduce code
duplication.

Reviewers: clayborg, jingham

Subscribers: jfb, mgorny, lldb-commits

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

llvm-svn: 367418

[DivRemPairs] Avoid RAUW pitfalls (PR42823)

Summary:
`DivRemPairs` internally creates two maps:
* {sign, divident, divisor} -> div instruction
* {sign, divident, divisor} -> rem instruction
Then it iterates over rem map, and looks if there is an entry
in div map with the same key. Then depending on some internal logic
it may RAUW rem instruction with something else.

But if that rem instruction is an input to other div/rem,
then it was used as a key in these maps, so the old value (used in key)
is now dandling, because RAUW didn't update those maps.
And we can't even RAUW map keys in general, there's `ValueMap`,
but we don't have a single `Value` as key...

The bug was discovered via D65298, and the test there exists.
Now, i'm not sure how to expose this issue in trunk.
The bug is clearly there if i change the map keys to be `AssertingVH`/`PoisoningVH`,
but i guess this didn't miscompiled anything thus far?
I really don't think this is benin without that patch.

The fix is actually rather straight-forward - instead of trying to somehow
shoe-horn `ValueMap` here (doesn't fit, key isn't just `Value`), or writing a new
`ValueMap` with key being a struct of `Value`s, we can just have an intermediate
data structure - a vector, each entry containing matching `Div, Rem` pair,
and pre-filling it before doing any modifications.
This way we won't need to query map after doing RAUW, so no bug is possible.

Reviewers: spatel, bogner, RKSimon, craig.topper

Reviewed By: spatel

Subscribers: hiraditya, hans, llvm-commits

Tags: #llvm

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

llvm-svn: 367417

[lldb][NFC] Check in another crashing test case

llvm-svn: 367416

[DivRemPairs][NFC] Autogenerate all checklines

llvm-svn: 367415

[ProcessWindows] Choose a register context file by preprocessor

Replaced Cmake option based check with the preprocessor macro as CMAKE_SYSTEM_PROCESSOR doesn't work as expected on Windows.

Fixes llvm.org/pr42724

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

llvm-svn: 367414

Add llvm-style RTTI to ObjectFile hierarchy

Summary:
On the heels of D62934, this patch uses the same approach to introduce
llvm RTTI support to the ObjectFile hierarchy. It also replaces the
existing uses of GetPluginName doing run-time type checks with
llvm::dyn_cast and friends.

This formally introduces new dependencies from some other plugins to
ObjectFile plugins. However, I believe this is fine because:
- these dependencies were already kind of there, and the only reason
  we could get away with not modeling them explicitly was because the
  code was relying on magically knowing what will GetPluginName() return
  for a particular kind of object files.
- the dependencies themselves are logical (it makes sense for
  SymbolVendorELF to depend on ObjectFileELF), or at least don't
  actively get in the way (the JitLoaderGDB->MachO thing).
- they don't introduce any new dependency loops as ObjectFile plugins
  don't depend on any other plugins

Reviewers: xiaobai, JDevlieghere, espindola

Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits

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

llvm-svn: 367413

[X86][AVX] Add reduced test case for PR42833

llvm-svn: 367412

[lldb][NFC] Check in completion crash test in lambda

llvm-svn: 367411

Add missing includes to SymbolFilePDBTests

These became needed after r367368.

llvm-svn: 367410

Re-disable C4324 MSVC warning that was enabled in D65458 / rL367383

This was breaking /WX builds

llvm-svn: 367409

[ARM] Generate MVE VFMAs

llvm-svn: 367408

[lldb][docs] Add CMake version notes for -B flag

The original documentation update was reviewed with D65330

llvm-svn: 367407

[Clangd] NFC: Added FIXME in ExtractVariable tests

llvm-svn: 367406

[NFC] Test Commit

llvm-svn: 367405

Fix mismatching vector type in AlignmentTest.cpp

llvm-svn: 367404

[RISCV] Support 'f' Inline Assembly Constraint

Summary:
This adds the 'f' inline assembly constraint, as supported by GCC. An
'f'-constrained operand is passed in a floating point register. Exactly
which kind of floating-point register (32-bit or 64-bit) is decided
based on the operand type and the available standard extensions (-f and
-d, respectively).

This patch adds support in both the clang frontend, and LLVM itself.

Reviewers: asb, lewis-revill

Reviewed By: asb

Subscribers: hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 367403

[NFC][ARMCGP] Use switch in isSupportedValue

Use a switch instead of many isa<> while checking for supported
values. Also be explicit about which cast instructions are supported;
This allows the removal of SIToFP from GenerateSignBits.

llvm-svn: 367402

Recommit "[GVN] Preserve loop related analysis/canonical forms."

This fixes some pipeline tests.
This reverts commit d0b6f42936bfb6d56d325c732ae79400c9c6016a.

llvm-svn: 367401

Add default constructor for MaybeAlign

llvm-svn: 367400

[RISCV] Add support for floating point registers in inlineasm

This adds support for parsing/emitting in IR the floating-point RISC-V
registers in inline assembly clobber lists.

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

llvm-svn: 367399

[AArch64][SVE2] Load/store instruction fixes

Summary:
* Loads and stores in SVE2 are gather/scatter not contiguous, fixed by
  renaming multiclasses to reflect this and also updated comments.
* Remove aliases from load/store multiclasses that reflect the behaviour
  of the original form.
* Fix bug in scatter store implementation, vector list should be used as
  input, not output.

Reviewed By: sdesmalen

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

llvm-svn: 367398

[RISCV] Add support for lowering floating point inlineasm clobbers

This adds the required extension to RISC-V's getRegForInlineAsmConstraint
in order to be able to correctly distringuish between the 32 and 64-bit
floating point registers when the generic fX name appears in inlineasm
clobber contraints. It also adds a check to validate that callee saved
floating point registers are only saved in this case when a hard-float
ABI is selected.

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

llvm-svn: 367397

[AArch64][SVE2] Minor refactoring and cleanup

Summary:
* Clarify comment with SVE2 for predicated shifts and move next to other
  shift instructions.
* Clarify comments for various instructions.
* Move FCVTX instruction next to other fp conversions.
* Move FLOGB to next to other fp instructions and fix description.
* Remove "cons" from non-constructive multiclass for bitwise shift-right
  and accumulate instructions.

Reviewed By: sdesmalen

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

llvm-svn: 367396

[docs] Add cmake to Software requirements

Add cmake to the list of packages required for compiling LLVM.
Also move make to the bottom of the list and mark it as optional.

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

llvm-svn: 367395

[AArch64][SVE2] Use destination register as source register

Summary:
This patch fixes a bug in the following instructions that should have been
implemented as destructive. A destructive instruction is an instruction where
one of the source registers also acts as the destination register. Therefore,
the contents of the source register, when the instruction begins execution, are
replaced by the result of the instruction when the instruction completes
execution [1]:

  * SRI/SLI
  * EORBT/EORTB
  * TBX
  * Narrowing top instructions
  * FP convert precision instructions

These changes are non-functional from the assembler/diassembler point-of-view
but are necessary for correct codegen.

[1] https://static.docs.arm.com/ddi0584/ae/DDI0584A_e_SVE_supp_armv8A.pdf

Reviewed By: sdesmalen

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

llvm-svn: 367394

[LLVM][NFC] Adding an Alignment type to LLVM

Summary:
This patch introduces a type to straighten LLVM's alignment management.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html

The next step is to use this type throughout LLVM

Reviewers: jfb, jakehehrlich

Subscribers: mgorny, mgrang, dexonsmith, llvm-commits, courbet

Tags: #llvm

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

llvm-svn: 367393

SymbolVendor: Remove the object file member variable

Summary:
The last responsibility of the SymbolVendor was to hold an owning
reference to the object file (in case symbols are being read from a
different file than the main module). As SymbolFile classes already hold
a non-owning reference to the object file, we can easily remove this
responsibility of the SymbolVendor by making the SymbolFile reference
owning.

Reviewers: JDevlieghere, clayborg, jingham

Subscribers: lldb-commits

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

llvm-svn: 367392

[llvm/Object] - Add a test for "empty string table" error.

This error was never tested. In this patch I improved
the error message, added the test case and also simplified
the code that processes a similar error right below.

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

llvm-svn: 367391

[ARM][ParallelDSP] Convert to function pass

Run across a whole function, visiting each basic block one at a time.

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

llvm-svn: 367389

revert r367382 because buildbot failure

llvm-svn: 367388

[Fix] Customize warnings for missing built-in types

If we detect a built-in declaration for which we cannot derive a type
matching the pattern in the Builtins.def file, we currently emit a
warning that the respective header is needed. However, this is not
necessarily the behavior we want as it has no connection to the location
of the declaration (which can actually be in the header in question).
Instead, this warning is generated
  - if we could not build the type for the pattern on file (for some
    reason). Here we should make the reason explicit. The actual problem
    is otherwise circumvented as the warning is misleading, see [0] for
    an example.
  - if we could not build the type for the pattern because we do not
    have a type on record, possible since D55483, we should not emit any
    warning. See [1] for a legitimate problem.

This patch address both cases. For the "setjmp" family a new warning is
introduced and for built-ins without type on record, so far
"pthread_create", we do not emit the warning anymore.

Also see: PR40692

[0] https://lkml.org/lkml/2019/1/11/718
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235583

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

llvm-svn: 367387

Change '|' to '&' in conditional.

Bitwise-or with a non-zero constant will always evaluate to true.  Switch to
bitwise-and which will only evalute to true if the specified bit is set in the
other operand.

llvm-svn: 367386

[CompletionRequest] Remove unimplemented members.

Completion requests have two fields that are essentially unimplemented:
`m_match_start_point` and `m_max_return_elements`. This would've been
okay, if it wasn't for the fact that this caused a bunch of useless
parameters to be passed around. Occasionally there would be a comment or
assert saying that they are not supported. This patch removes them.

llvm-svn: 367385

[StringList] Change LongestCommonPrefix API

When investigating a completion bug I got confused by the API.
LongestCommonPrefix finds the longest common prefix of the strings in
the string list. Instead of returning that string through an output
argument, just return it by value.

llvm-svn: 367384

[NFC] Remove LLVM_ALIGNAS

Summary: The minimum compilers support all have alignas, and we don't use LLVM_ALIGNAS anywhere anymore. This also removes an MSVC diagnostic which, according to the comment above, isn't relevant anymore.

Reviewers: rnk

Subscribers: mgorny, jkorous, dexonsmith, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 367383

[PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store

In PowerPC, there is instruction to load vector in big endian element order when it's in little endian target.
So we can combine vector load + reverse into big endian load to eliminate the swap instruction.
Also combine vector reverse + store into big endian store.

llvm-svn: 367382

[AMDGPU] Fix high occupancy calculation and print it

We had couple places which still return 10 as a maximum
occupancy. Fixed.

Also print comment about occupancy as compiler see it.

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

llvm-svn: 367381

[asan_symbolize] More debugging output

When a line fails to match the stackframe regex we now report
it in the log.

rdar://problem/49476995

llvm-svn: 367380

[asan_symbolize] Add `--skip-uuid-validation` option to `ModuleMapPlugIn`.

This option disables the validation of binary UUIDs. This is useful
in environments where the `otool` binary is not available.

rdar://problem/49476995

llvm-svn: 367379

[asan_symbolize] Provide better error message when extracting the UUID of a binary fails

rdar://problem/49476995

llvm-svn: 367378

[TableGen] Move helpers into LLDBTableGenUtils.

Instead of polluting the LLDBTableGenBackends header with helpers used
by both emitters, move them into a separate files.

llvm-svn: 367377

GlobalISel: Replace artifact combiner checks with assert

It has bothered me for a while that these guard against cases that
should never happene, so replace these with asserts.

llvm-svn: 367376

[TableGen] Include vector

Fixes "no member named 'vector' in namespace 'std'" compile error.

llvm-svn: 367375

[MS] Emit S_HEAPALLOCSITE debug info in SelectionDAG

Summary: This emits labels around heapallocsite calls in SelectionDAG.

Reviewers: rnk

Subscribers: MatzeB, aprantl, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367374

TableGen: Add MinAlignment predicate

AMDGPU uses some custom code predicates for testing alignments.

I'm still having trouble comprehending the behavior of predicate bits
in the PatFrag hierarchy. Any attempt to abstract these properties
unexpectdly fails to apply them.

llvm-svn: 367373

Reland: [Remarks] Add an LLVM-bitstream-based remark serializer

Add a new serializer, using a binary format based on the LLVM bitstream
format.

This format provides a way to serialize the remarks in two modes:

1) Separate mode: the metadata is separate from the remark entries.
2) Standalone mode: the metadata and the remark entries are in the same
file.

The format contains:

* a meta block: container version, container type, string table,
external file path, remark version
* a remark block: type, remark name, pass name, function name, debug
file, debug line, debug column, hotness, arguments (key, value, debug
file, debug line, debug column)

A string table is required for this format, which will be dumped in the
meta block to be consumed before parsing the remark blocks.

On clang itself, we noticed a size reduction of 13.4x compared to YAML,
and a compile-time reduction of between 1.7% and 3.5% on CTMark.

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

Original llvm-svn: 367364
Revert llvm-svn: 367370

llvm-svn: 367372

NFCI, optimize layout of FileEntry

The reordering of the UID field makes the size of a
FileEntry 8 bytes smaller on 64bit platforms.

llvm-svn: 367371

Revert "[Remarks] Add an LLVM-bitstream-based remark serializer"

This reverts commit r367364.

Breaks some bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-gn/builds/3161/steps/annotate/logs/stdio

llvm-svn: 367370

GlobalISel: Add G_ATOMICRMW_{FADD|FSUB}

llvm-svn: 367369

[SymbolFilePDB] Fix windows bots after rL367360

SymbolFilePDB tests were using GetTypeSystemForLanguage but weren't
changed to accomodate the use of an llvm::Expected. I adjusted them
accordingly.

llvm-svn: 367368

[Sema] Actually map a variable template specialization from pattern to instantiation

We were previously just using a specialization in the class template instead of
creating a new specialization in the class instantiation.

Fixes llvm.org/PR42779.

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

llvm-svn: 367367

gn build: Merge r367364

llvm-svn: 367366

[DAGCombiner] Add an option to control whether or not to enable store merging.

Add an option to control whether or not to enable store merging in dag combiner
so we can workaround some bugs more easily.

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

llvm-svn: 367365