Add Rest of Targets Support to ValidCPUList (enabling march notes)

A followup to: https://reviews.llvm.org/D42978

Most of the rest of the Targets were pretty rote, so this
patch knocks them all out at once.

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

llvm-svn: 324676

Add NVPTX Support to ValidCPUList (enabling march notes)

A followup to: https://reviews.llvm.org/D42978
This patch adds NVPTX support for
enabling the march notes.

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

llvm-svn: 324675

Add X86 Support to ValidCPUList (enabling march notes)

A followup to: https://reviews.llvm.org/D42978
This patch adds X86 and X86_64 support for
enabling the march notes.

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

llvm-svn: 324674

Make march/target-cpu print a note with the list of valid values for ARM

When rejecting a march= or target-cpu command line parameter,
the message is quite lacking. This patch adds a note that prints
all possible values for the current target, if the target supports it.

This adds support for the ARM/AArch64 targets (more to come!).

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

llvm-svn: 324673

Recognize MSVC style mangling in CPlusPlusLanguage::IsCPPMangledName

Reviewers: zturner, lldb-commits, labath

Reviewed By: zturner

Subscribers: jingham, labath, davide, llvm-commits

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

llvm-svn: 324672

Only throw -fPIC when building a shared library

Summary:
Update makefiles to specify -fPIC in Makefile.rules and only throw -fPIC when building a shared library. This change is necessary to allow building the lldb tests on Windows where -fPIC is not a valid option.

Update a few places to Python 3.x syntax

Reviewers: zturner, lldb-commits

Reviewed By: zturner

Subscribers: stella.stamenova, labath, llvm-commits

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

llvm-svn: 324671

Minor tweak to test case.

llvm-svn: 324670

[DWARFv5] Fix dumper to show the file table starts at index 0.

Emitting the correct (root of compilation) file at index 0 will be
posted for review later; I wanted to get this minor change out of the
way first.

llvm-svn: 324669

[CFG] Add extra context to C++ constructor statement elements.

This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces
the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional
information to provide regarding what sort of object is being constructed.

It is useful for figuring out what memory is initialized in client of the
CFG such as the Static Analyzer, which do not operate by recursive AST
traversal, but instead rely on the CFG to provide all the information when they
need it. Otherwise, the statement that triggers the construction and defines
what memory is being initialized would normally occur after the
construct-expression, and the client would need to peek to the next CFG element
or use statement parent map to understand the necessary facts about
the construct-expression.

As a proof of concept, CFGConstructors are added for new-expressions
and the respective test cases are provided to demonstrate how it works.

For now, the only additional data contained in the CFGConstructor element is
the "trigger statement", such as new-expression, which is the parent of the
constructor. It will be significantly expanded in later commits. The additional
data is organized as an auxiliary structure - the "construction context",
which is allocated separately from the CFGElement.

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

llvm-svn: 324668

AMDGPU: Process SDWA block at a time

Right now this loops over the entire function every time there
is a change, which is not very efficient. There's no practical
reason to track this so globally, since the code motion optimization
passes should be sinking instructions with single uses and
the pass currently will not fold with multiple uses.

llvm-svn: 324667

AMDGPU: Minor cleanups

Column limit, typo, unnecessary reference

llvm-svn: 324666

[GlobalISel][X86] Fixing failures after https://reviews.llvm.org/D37775

The patch essentially makes sure that X86CallLowering adds proper
G_COPY/G_TRUNC and G_ANYEXT/G_COPY when we are doing lowering of
arguments/returns for floating point values passed on registers.

Tests are updated accordingly

Reviewed By: qcolombet

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

llvm-svn: 324665

[GlobalIsel][X86] Making {G_IMPLICIT_DEF, s128} legal

The patch is a split from D42287 and is related to
fixing failures after https://reviews.llvm.org/D37775

Reviewed By: qcolombet

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

llvm-svn: 324664

[analyzer] Self-debug: Dump the core's internal state traits to the egraph.

It is useful for debugging problems with C++ operator new() or temporaries.

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

llvm-svn: 324663

[X86] Improve combineCastedMaskArithmetic to fold (bitcast (vXi1 (and/or/xor X, C)))->(vXi1 (and/or/xor (bitcast X), (bitcast C)) where C is a constant build_vector.

Most vxi1 constant build vectors have to be implemented in the scalar domain anyway so we'll probably end up with a cast there later. But by then its too late to do the combine to get rid of it.

llvm-svn: 324662

[X86] Add DAG combine to constant fold a bitcast of a vXi1 constant build_vector into a scalar integer.

llvm-svn: 324661

[analyzer] Self-debug: Dump environment frame-by-frame.

It makes it easier to discriminate between values of similar expressions
in different stack frames.

It also makes the separate backtrace section in ExplodedGraph dumps redundant.

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

llvm-svn: 324660

CMake: Explicitly #undef LLVM_REVISION rather than using a blank file

Including a blank file is confusing and makes it look like something
went wrong. Rather than requiring people know why this is blank, let's
just make it explicitly #undef the macro that it would define if it
weren't empty.

llvm-svn: 324659

[ThinLTO] Skip BlockAddresses while replacing uses in function import.

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

llvm-svn: 324658

Parameterize a test.

llvm-svn: 324657

[ELF] Don't sort non reorderable sections with --symbol-ordering-file

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

llvm-svn: 324656

Rewrite testcase to not depend on Foundation implementation details.

TODO: Add a separate testcase testing *only* Foundation implementation details!

<rdar://problem/37252738>

llvm-svn: 324655

[DSan] Update uses of memory intrinsic get/setAlignment to new API (NFC)

Summary:
This change is part of step five in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the
DataFlowSanitizer pass to cease using the old get/setAlignment() API of MemoryIntrinsic
in favour of getting source & dest specific alignments through the new API.

Steps:
Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API. ( rC323617 )
Step 4) Update Polly to use the new IRBuilder API. ( rL323618 )
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment()
and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278,
rL324384, rL324395, rL324402, rL324626, rL324642, rL324653 )
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.

Reference
   http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html
   http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html

llvm-svn: 324654

[ASan] Update uses of IRBuilder::CreateMemCpy to new API (NFC)

Summary:
This change is part of step five in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the
AddressSanitizer pass to cease using The old IRBuilder CreateMemCpy single-alignment API
in favour of the new API that allows setting source and destination alignments independently.

Steps:
Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API. ( rC323617 )
Step 4) Update Polly to use the new IRBuilder API. ( rL323618 )
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment()
and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278,
rL324384, rL324395, rL324402, rL324626, rL324642 )
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.

Reference
   http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html
   http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html

llvm-svn: 324653

[analyzer] [tests] Test different projects concurrently

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

llvm-svn: 324652

PR36307: Consume the #pragma options align annotation token after
semantic analysis to prevent incorrect -Wpragma-pack warning for an included
file

rdar://37354951

llvm-svn: 324651

Revert "WIP: [DAGCombiner] Assert that debug info is preserved"

This reverts commit r324648. It was committed accidentally.

llvm-svn: 324650

[bugpoint] Simplify the global initializer reducer, NFC

Fix the comments, use early exits, use unique_ptr, and use ranged for
loops.

This is in preparation for a global *variable* reducer, which, with any
luck will help us clean up test cases.

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

llvm-svn: 324649

WIP: [DAGCombiner] Assert that debug info is preserved

llvm-svn: 324648

[X86] Replace kortest intrinsics with native IR.

llvm-svn: 324647

[X86] Remove kortest intrinsics and replace with native IR.

llvm-svn: 324646

[X86] Support 'V' register operand modifier

This allows the register name to be printed without the leading '%'.
This can be used for emitting calls to the retpoline thunks from inline
asm.

llvm-svn: 324645

Fix improper indentation issue in CodeGenModule [NFC]

llvm-svn: 324644

Fix missing field initializer warning in TableGen SubtargetEmitter

llvm-svn: 324643

[MSan] Update uses of IRBuilder::CreateMemCpy to new API (NFC)

Summary:
This change is part of step five in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the
MemorySanitizer pass to cease using the old IRBuilder CreateMemCpy single-alignment APIs
in favour of the new API that allows setting source and destination alignments independently.

Steps:
Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API. ( rC323617 )
Step 4) Update Polly to use the new IRBuilder API. ( rL323618 )
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment()
and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278,
rL324384, rL324395, rL324402, rL324626 )
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.

Reference
   http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html
   http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html

llvm-svn: 324642

Fix crash on array initializer with non-0 alloca addrspace

llvm-svn: 324641

The apple versions of clang don't support deduction guides yet.

llvm-svn: 324640

Regenerate test

llvm-svn: 324639

[X86] Add common CHECK prefix to shift combine tests

llvm-svn: 324638

[X86] Add shift undef, %X tests

llvm-svn: 324637

[InstCombine] visitSRem - use m_Negative(APInt) helper. NFCI.

llvm-svn: 324636

[InstCombine] Add vector udiv tests

Tests for X udiv C, where C >= signbit

llvm-svn: 324635

[SelectionDAG] Add a helper function for creating a boolean constant based on the target's boolean content

Many in SimplifySetCC and FoldSetCC try to create true or false constants. Some of them query getBooleanContents to figure out whether to use all ones or just 1 for true. But many places do not check and just use 1 without ensuring the VT has an i1 scalar type. Note sure if those places only trigger before type legalization so they only see an i1
type?

To cleanup the inconsistency and reduce some duplicated code, this patch adds a getBoolConstant method to SelectionDAG that takes are of querying getBooleanContents and doing the right thing.

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

llvm-svn: 324634

Simplify function prototypes in bugpoint, NFC

llvm-svn: 324633

Change "UNSUPPORTED: windows" to be "UNSUPPORTED: system-windows" so that test is actually skipped on Windows.

Reviewed by Paul Robinson

llvm-svn: 324632

[InstCombine] Add m_Negative pattern matching

Allows us to add non-uniform constant vector support for "X urem C -> X < C ? X : X - C, where C >= signbit."

llvm-svn: 324631

[X86] Add a few new test cases for shrunkblend combine

One of them shows a missed opportunity to use SimplifyDemandedBits on the condition when its used by multiple vselects.

The other is a case we shouldn't optimize because the condition has a non-vselect use.

llvm-svn: 324630

[InstCombine] Add vector urem tests.

Improve coverage of InstCombiner::visitURem for vector types

llvm-svn: 324629

Use ranged for loops in TypeFinder.cpp, NFC

llvm-svn: 324628

[InstCombine] Regenerate vector mul tests.

llvm-svn: 324627

[LoopIdiom] Be more aggressive when setting alignment in memcpy

Summary:
This change is part of step five in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the
LoopIdiom pass to cease using the old IRBuilder CreateMemCpy single-alignment APIs in
favour of the new API that allows setting source and destination alignments independently.
This allows us to be slightly more aggressive in setting the alignment of memcpy calls that
loop idiom creates.

Steps:
Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API. ( rC323617 )
Step 4) Update Polly to use the new IRBuilder API. ( rL323618 )
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment()
and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278,
rL324384, rL324395, rL324402 )
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.

Reference
   http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html
   http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html

llvm-svn: 324626

Fix signed/unsigned compare warning I introduced

'size' of a vector is unsigned, and I accidentially compared
it to an int through GTEST.  I switched it to unsigned, which
is the template parameter type anyway.

llvm-svn: 324625

Once more, with feeling. Spell 'clang-4.0' correctly this time

llvm-svn: 324624

[ARM] Add 'fillValidCPUArchList' to ARM targets

This is a support change for a CFE change (https://reviews.llvm.org/D42978)
that allows march and -target-cpu to list the valid targets in a note. The changes
are limited to the ARM/AArch64, since this is the only target that gets the CPU
list from LLVM.

llvm-svn: 324623

[dsymutil] Use llvm::sys::path to join bundle path.

When processing a dSYM bundle, use llvm::sys::path to join the different
path components instead of using a string with hard coded forward
slashes as separators.

llvm-svn: 324622

[dwarfdump] Normalize input path.

Before this patch, llvm-dwarfdump would reject `bundel.dSYM/` as input,
while `bundel.dSYM` was accepted. The reason is that `path::extension()`
returns an empty string for the former, leading to the argument not
being recognized as a dSYM bundle.

llvm-svn: 324621

[scudo] Allow options to be defined at compile time

Summary:
Allow for options to be defined at compile time, like is already the case for
other sanitizers, via `SCUDO_DEFAULT_OPTIONS`.

Reviewers: alekseyshl, dberris

Reviewed By: alekseyshl, dberris

Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers

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

llvm-svn: 324620

Clean up string's deduction guides tests. Mark old versions of clang as unsupported, b/c they don't have deduction guides, even in C++17 mode

llvm-svn: 324619

[clang-format] Do not break Objective-C string literals inside array literals

Summary:
Concatenating Objective-C string literals inside an array literal
raises the warning -Wobjc-string-concatenation (which is enabled by default).

clang-format currently splits and concatenates string literals like
the following:

  NSArray *myArray = @[ @"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" ];

into:

  NSArray *myArray =
        @[ @"aaaaaaaaaaaaaaaaaaaaaaaaaaaa"
           @"aaaaaaaaa" ];

which raises the warning. This is https://bugs.llvm.org/show_bug.cgi?id=36153 .

The options I can think of to fix this are:

1) Have clang-format disable Wobjc-string-concatenation by emitting
pragmas around the formatted code
2) Have clang-format wrap the string literals in a macro (which
disables the warning)
3) Disable string splitting for Objective-C string literals inside
array literals

I think 1) has no precedent, and I couldn't find a good
identity() macro for 2). So, this diff implements 3).

Test Plan: make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests

Reviewers: jolesiak, stephanemoore, djasper

Reviewed By: jolesiak

Subscribers: klimek, cfe-commits

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

llvm-svn: 324618

[AMDGPU] Updae documentation about address space

llvm-svn: 324617

[SLPVectorizer] auto-generate complete checks; NFC

llvm-svn: 324616

[SLPVectorizer] auto-generate complete checks; NFC

llvm-svn: 324615

[SLPVectorizer] move RUN line to top-of-file; NFC

I was confused what we were checking because the RUN line was
in the middle of the file.

llvm-svn: 324614

[InstCombine] Fix issue with X udiv (POW2_C1 << N) for non-splat constant vectors

foldUDivShl was assuming that the input was a scalar or a splat constant

llvm-svn: 324613

[SLPVectorizer] auto-generate complete checks; NFC

llvm-svn: 324612

[LoopVectorize] auto-generate complete checks; NFC

llvm-svn: 324611

[ValueTracking] don't crash when assumptions conflict (PR36270)

The last assume in the test says that %B12 is 0.
The first assume says that %and1 is less than %B12.
Therefore, %and1 is unsigned less than 0...does not compute.

That means this line:
Known.Zero.setHighBits(RHSKnown.countMinLeadingZeros() + 1);
...tries to set more bits than exist.

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

llvm-svn: 324610

Update the status of removed components

llvm-svn: 324609

[InstCombine] Fix issue with X udiv 2^C -> X >> C for non-splat constant vectors

foldUDivPow2Cst was assuming that the input was a scalar or a splat constant

llvm-svn: 324608

[Parser][FixIt] Better diagnostics for "typedef" instead of "typename" typo

rdar://problem/10214588

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

llvm-svn: 324607

[ARM] Re-commit r324600 with fixed LLVMBuild.txt

ARMDisassembler now depends on the banked register tables in ARMUtils, so the
LLVMBuild.txt needed updating to reflect this.

Original commit mesage:

[ARM] Fix disassembly of invalid banked register moves

When disassembling banked register move instructions, we don't have an
assembly syntax for the unallocated register numbers, so we have to
return Fail rather than SoftFail. Previously we were returning SoftFail,
then crashing in the InstPrinter as we have no way to represent these
encodings in an assembly string.

This also switches the decoder to use the table-generated list of banked
registers, removing the duplicated list of encodings.

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

llvm-svn: 324606

Fix unused variable warning.

llvm-svn: 324605

Revert r324600 as it breaks a buildbot

The broken bot (clang-ppc64le-linux-multistage) is doign a shared-object build,
so I guess using lookupBankedRegByEncoding in the disassembler is a layering
violation?

llvm-svn: 324604

[InstCombine] Improve mul(x, pow2) -> shl combine for vector constants

Refactor getLogBase2Vector into getLogBase2 to accept all scalars/vectors. Generalize from ConstantDataVector to support all constant vectors.

llvm-svn: 324603

[x86] Add test/CodeGen/X86/vmaskmov-offset.ll. NFC.

Needed for checking current code generation.

llvm-svn: 324601

[ARM] Fix disassembly of invalid banked register moves

When disassembling banked register move instructions, we don't have an
assembly syntax for the unallocated register numbers, so we have to
return Fail rather than SoftFail. Previously we were returning SoftFail,
then crashing in the InstPrinter as we have no way to represent these
encodings in an assembly string.

This also switches the decoder to use the table-generated list of banked
registers, removing the duplicated list of encodings.

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

llvm-svn: 324600

[clangd] Update include guard in Annotations.h. NFC

llvm-svn: 324599

[test][dsymutil] Fix tests for Windows bots.

The UNSUPPORTED directive was not honored by the bot, presumably because
of the FIXME above it. This moves the comment down and removes the
remaining update check from basic-linking-x86.test.

This should un-break: llvm-clang-x86_64-expensive-checks-win/builds/7798/

llvm-svn: 324598

Add missed PostDominatorTree analysis dependency to GVN hoist pass.

Summary:
GVN hoist pass is using PostDominatorTree analysis, therefore the analysis
should be listed in the pass initialization as a dependency.

Reviewed By: sebpop

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

Author: ashlykov <arkady.shlykov@intel.com>
llvm-svn: 324597

[libcxx] Avoid spurious construction of valarray elements

Summary:
Currently libc++ implements some operations on valarray by using the
resize method. This method has a parameter with a default value.
Because of this, valarray may spuriously construct and destruct
objects of valarray's element type.

This patch fixes this issue and adds corresponding test cases.

Reviewers: EricWF, mclow.lists

Reviewed By: mclow.lists

Subscribers: rogfer01, cfe-commits

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

llvm-svn: 324596

[X86][MC]: Adding test coverage of MC encoding for several small extensions.<NFC>

NFC.
 Adding MC regressions tests to cover several small x86 extensions as follows:
 CLWB, CLZERO, F16C, INVPCID, PKU, POPCNT, RTM, SGX, SHA, SVM, VMFUNC, VTX

This patch is part of a larger task to cover MC encoding of all X86 isa sets started in revision: https://reviews.llvm.org/D39952

Reviewers: RKSimon, craig.topper, zvi, AndreiGrischenko
Differential Revision: https://reviews.llvm.org/D41388

Change-Id: I254508cd17faca00b780be0fc2abf6c71b61faab
llvm-svn: 324595

Fix for #31362 - ms_abi is implemented incorrectly for values >=16 bytes.

Summary:
This patch is a fix for following issue:
https://bugs.llvm.org/show_bug.cgi?id=31362 The problem was caused by front end
lowering C calling conventions without taking into account calling conventions
enforced by attribute. In this case win64cc was no correctly lowered on targets
other than Windows.

Reviewed By: rnk (Reid Kleckner)

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

Author: belickim <mateusz.belicki@intel.com>
llvm-svn: 324594

[builtins] Workaround for infinite recursion in c?zdi2

gcc resolves `__builtin_c?z` to `__c?zdi2` which leads to infinite
recursion. This problem has been observed for sparc64, mips64 and riscv.
Presumably this happens whenever an arch without dedicated bit counting
instructions is targeted. This patch provides a workaround.

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

llvm-svn: 324593

Re-land [dsymutil] Upstream update feature

This commit attempts to re-land the r324480 which was reverted in
r324493 because it broke the Windows bots. For now I disabled the two
update tests on Windows until I'm able to debug this.

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

llvm-svn: 324592

[clang-format] Do not break before long string literals in protos

Summary:
This patch is a follow-up to r323319 (which disables string literal breaking for
text protos) and it disables breaking before long string literals.

For example this:
```
keyyyyy: "long string literal"
```
used to get broken into:
```
keyyyyy:
    "long string literal"
```

While at it, I also enabled it for LK_Proto and fixed a bug in the mustBreak code.

Reviewers: djasper, sammccall

Reviewed By: djasper

Subscribers: klimek, cfe-commits

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

llvm-svn: 324591

Rewrite the flaky test_restart_bug test in a more deterministic way

Summary:
The test was trying to reproduce a bug in handling of two concurrent
events, which was impossible to do reliably in a black-box style test.
In practice, this meant the test was only ever failing on remote
targets, as these were slow enough to trigger this.

Fortunately, we now have the ability to mock the server side of the
connection, which means we can simulate the failure deterministically,
so I rewrite the test to use the new gdb-client framework.

I've needed to add a couple of new packets to the mock server to be able
to do this. Instead of trying to guess how a "typical" gdb-client test
will want to handle this, I throw an exception in the implementation to
force the user to override them (the packets are only sent if the test
explicitly performs some action which will trigger them, so a basic test
which e.g. does not need the "continue" functionality will not need to
implement them).

Reviewers: owenpshaw

Subscribers: srhines, lldb-commits

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

llvm-svn: 324590

[Loop Predication] Teach LP about reverse loops with uge and sge latch conditions

Add support of uge and sge latch condition to Loop Prediction for
reverse loops.

Reviewers: apilipenko, mkazantsev, sanjoy, anna
Reviewed By: anna
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42837

llvm-svn: 324589

[OMPT] Add tool_available_search testcase

Tests the search for tools as defined in the spec. The OMP_TOOL_LIBRARIES
environment variable contains paths to the following files(in that order)

-to a nonexisting file
-to a shared library that does not have a ompt_start_tool function
-to a shared library that has an ompt_start_tool implementation returning NULL
-to a shared library that has an ompt_start_tool implementation returning a
    pointer to a valid instance of ompt_start_tool_result_t

The expected result is that the last tool gets active and can print in the
thread-begin callback.

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

llvm-svn: 324588

[OMPT] Add tool_not_available testcase

Add a testcase that checks wheter the runtime can handle an ompt_start_tool
method that returns NULL indicating that no tool shall be loaded.

All tool_available testcases need a separate folder to avoid file conflicts for
the generated tools.

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

llvm-svn: 324587

[X86] Fix compilation of r324580.

@ctopper Can you check that the fix is correct ?

llvm-svn: 324586

Revert accidental changes that snuck in r324584

llvm-svn: 324585

[mips] Define certain instructions in microMIPS32r3

Instructions affected:
mthc1, mfhc1, add.d, sub.d, mul.d, div.d,
mov.d, neg.d, cvt.w.d, cvt.d.s, cvt.d.w, cvt.s.d

These instructions are now defined for
microMIPS32r3 + microMIPS32r6 in MicroMipsInstrFPU.td
since they shared their encoding with those already defined
in microMIPS32r6InstrInfo.td and have been therefore
removed from the latter file.

Some instructions present in MicroMipsInstrFPU.td which
did not have both AFGR64 and FGR64 variants defined have
been altered to do so.

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

llvm-svn: 324584

[AVR] Fix the testsuite after '%' changed to '$' in MIR

llvm-svn: 324583

[TargetSchedule] Expose sub-units of a ProcResGroup in MCProcResourceDesc.

Summary:
Right now using a ProcResource automatically counts as usage of all
super ProcResGroups. All this is done during codegen, so there is no
way for schedulers to get this information at runtime.

This adds the information of which individual ProcRes units are
contained in a ProcResGroup in MCProcResourceDesc.

Reviewers: gchatelet

Subscribers: llvm-commits

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

llvm-svn: 324582

[AArch64] Don't materialize 0 with "fmov h0, .." when FullFP16 is not supported

We were generating "fmov h0, wzr" instructions when FullFP16 is not enabled.
I've not added any tests, because the problem was visible in:
test/CodeGen/AArch64/arm64-zero-cycle-zeroing.ll,
which I had to change: I don't think Cyclone has FullFP16 enabled
by default, so it shouldn't be using this v8.2a instruction.

I've also removed these rdar tags, please shout if there are any objections.

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

llvm-svn: 324581

[X86] Support folding in a k-register OR when creating KORTEST from scalar compare of a bitcast from vXi1.

This should allow us to remove the kortest intrinsic from IR and use compare+bitcast+or in IR instead.

llvm-svn: 324580

[X86] Allow KORTEST instruction to be used for testing if a mask is all ones

The KTEST instruction sets the C flag if the result of anding both operands together is all 1s. We can use this to lower (icmp eq/ne (bitcast (vXi1 X), -1)

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

llvm-svn: 324577

[X86] Don't emit KTEST instructions unless only the Z flag is being used

Summary:
KTEST has weird flag behavior. The Z flag is set for all bits in the AND of the k-registers being 0, and the C flag is set for all bits being 1. All other flags are cleared.

We currently emit this instruction in EmitTEST and don't check the condition code. This can lead to strange things like using the S flag after a KTEST for a signed compare.

The domain reassignment pass can also transform TEST instructions into KTEST and is not protected against the flag usage either. For now I've disabled this part of the domain reassignment pass. I tried to comment out the checks in the mir test so that we could recover them later, but I couldn't figure out how to get that to work.

This patch moves the KTEST handling into LowerSETCC and now creates a ktest+x86setcc. I've chosen this approach because I'd like to add support for the C flag for all ones in a followup patch. To do that requires that I can rewrite the condition code going in the x86setcc to be different than the original SETCC condition code.

This fixes PR36182. I'll file a PR to fix domain reassignment once this goes in. Should this be merged to 6.0?

Reviewers: spatel, guyblank, RKSimon, zvi

Reviewed By: guyblank

Subscribers: llvm-commits

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

llvm-svn: 324576

Resubmit "[clangd] The new threading implementation"

Initially submitted as r324356 and reverted in r324386.

This change additionally contains a fix to crashes of the buildbots.
The source of the crash was undefined behaviour caused by
std::future<> whose std::promise<> was destroyed without calling
set_value().

llvm-svn: 324575

Recommit r324455 "[ThinLTO] - Simplify code in ThinLTOBitcodeWriter."

With fix: reimplemented.

Original commit message:
Recently introduced convertToDeclaration is very similar
to code used in filterModule function.
Patch reuses it to reduce duplication.

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

llvm-svn: 324574