AMDGPU: Remove llvm.SI.buffer.load.dword

llvm-svn: 348616

AMDGPU: Remove llvm.AMDGPU.kill

This is the last of the old AMDGPU intrinsics.

llvm-svn: 348615

[CTU] test/Analysis/ctu-main.cpp Attempt to fix failing windows bot

llvm-svn: 348614

Adding an AST dump test for statement expressions; NFC.

llvm-svn: 348613

Make testcase more robust for completely-out-of-tree builds.

Thats to Dave Zarzycki for reprorting this!

llvm-svn: 348612

[libcxx] Add paranoid cast-to-void in comma operator

llvm-svn: 348611

[CTU] Add triple/lang mismatch handling

Summary:
We introduce a strict policy for C++ CTU. It can work across TUs only if
the C++ dialects are the same. We neither allow C vs C++ CTU.  We do this
because the same constructs might be represented with different properties in
the corresponding AST nodes or even the nodes might be completely different (a
struct will be RecordDecl in C, but it will be a CXXRectordDecl in C++, thus it
may cause certain assertions during cast operations).

Reviewers: xazax.hun, a_sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

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

llvm-svn: 348610

[CTU] test/Analysis/ctu-main.cpp Attempt to fix failing windows bot

llvm-svn: 348609

[test] Mark atime-based tests unsupported on NetBSD

Mark tests requiring 'touch' to set atime unsupported on NetBSD
due to kernel limitation preventing it from working with noatime.

llvm-svn: 348607

[OPENMP][NVPTX]Save registers for optimized builds with enabled logging.

Summary:
Introduced special noinline function log that allows to save some
registers for optimized builds but with enabled logging. Also, it
increases the stability of the optimized builds with inlined runtime.

Reviewers: gtbercea, kkwli0

Reviewed By: gtbercea

Subscribers: caomhin, guansong, openmp-commits

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

llvm-svn: 348606

[CTU] Add more lit tests and better error handling

Summary:
Adding some more CTU list tests. E.g. to check if a construct is unsupported.
We also slightly modify the handling of the return value of the `Import`
function from ASTImporter.

Reviewers: xazax.hun, balazske, a_sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

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

llvm-svn: 348605

[DAGCombiner] disable truncation of binops by default

As discussed in the post-commit thread of r347917, this
transform is fighting with an existing transform causing
an infinite loop or out-of-memory, so this is effectively
reverting r347917 and its follow-up r348195 while we
investigate the bug.

llvm-svn: 348604

[unittests] Add C++17 and C++2a support to the tooling tests

llvm-svn: 348603

Reapply "[DemandedBits][BDCE] Support vectors of integers"

DemandedBits and BDCE currently only support scalar integers. This
patch extends them to also handle vector integer operations. In this
case bits are not tracked for individual vector elements, instead a
bit is demanded if it is demanded for any of the elements. This matches
the behavior of computeKnownBits in ValueTracking and
SimplifyDemandedBits in InstCombine.

Unlike the previous iteration of this patch, getDemandedBits() can now
again be called on arbirary (sized) instructions, even if they don't
have integer or vector of integer type. (For vector types the size of the
returned mask will now be the scalar size in bits though.)

The added LoopVectorize test case shows a case which triggered an
assertion failure with the previous attempt, because getDemandedBits()
was called on a pointer-typed instruction.

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

llvm-svn: 348602

[AMDGPU] Shrink scalar AND, OR, XOR instructions

This change attempts to shrink scalar AND, OR and XOR instructions which take an immediate that isn't inlineable.

It performs:
AND s0, s0, ~(1 << n) -> BITSET0 s0, n
OR s0, s0, (1 << n) -> BITSET1 s0, n
AND s0, s1, x -> ANDN2 s0, s1, ~x
OR s0, s1, x -> ORN2 s0, s1, ~x
XOR s0, s1, x -> XNOR s0, s1, ~x

In particular, this catches setting and clearing the sign bit for fabs (and x, 0x7ffffffff -> bitset0 x, 31 and or x, 0x80000000 -> bitset1 x, 31).

llvm-svn: 348601

Make CPUDispatch resolver emit dependent functions.

Inline cpu_specific versions referenced before the cpu_dispatch function
weren't properly emitted, since they hadn't been referred to.  This
patch ensures that during resolver generation that all appropriate
versions are emitted.

Change-Id: I94c3766aaf9c75ca07a0ad8258efdbb834654ff8
llvm-svn: 348600

Add an explicit triple to this test to prevent failures due to size_t differences.

llvm-svn: 348599

Fix spelling of WINDOWS in a test

Change-Id: I232515655359f14308e1c5509c4b7db96d1fafcb
llvm-svn: 348598

[DAGCombiner] remove explicit calls to AddToWorkList; NFCI

As noted in the post-commit thread for rL347917:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181203/608936.html
...we don't need to repeat these calls because the combiner does it automatically.

llvm-svn: 348597

Adding tests for -ast-dump; NFC.

This adds tests for various statements in C++ that are not covered by C.

llvm-svn: 348596

Revert "Multiversioning- Ensure all MV functions are emitted."

This reverts commit 65df29f9318ac13a633c0ce13b2b0bccf06e79ca.

AS suggested by @rsmith here: https://reviews.llvm.org/rL345839
I'm reverting this and solving the initial problem in a different way.

llvm-svn: 348595

[CTU] Add DisplayCTUProgress analyzer switch

Summary:
With a new switch we may be able to print to stderr if a new TU is being loaded
during CTU.  This is very important for higher level scripts (like CodeChecker)
to be able to parse this output so they can create e.g. a zip file in case of
a Clang crash which contains all the related TU files.

Reviewers: xazax.hun, Szelethus, a_sidorin, george.karpenkov

Subscribers: whisperity, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp,

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

llvm-svn: 348594

Introduce llvm.experimental.widenable_condition intrinsic

This patch introduces a new instinsic `@llvm.experimental.widenable_condition`
that allows explicit representation for guards. It is an alternative to using
`@llvm.experimental.guard` intrinsic that does not contain implicit control flow.

We keep finding places where `@llvm.experimental.guard` is not supported or
treated too conservatively, and there are 2 reasons to that:

- `@llvm.experimental.guard` has memory write side effect to model implicit control flow,
  and this sometimes confuses passes and analyzes that work with memory;
- Not all passes and analysis are aware of the semantics of guards. These passes treat them
  as regular throwing call and have no idea that the condition of guard may be used to prove
  something. One well-known place which had caused us troubles in the past is explicit loop
  iteration count calculation in SCEV. Another example is new loop unswitching which is not
  aware of guards. Whenever a new pass appears, we potentially have this problem there.

Rather than go and fix all these places (and commit to keep track of them and add support
in future), it seems more reasonable to leverage the existing optimizer's logic as much as possible.
The only significant difference between guards and regular explicit branches is that guard's condition
can be widened. It means that a guard contains (explicitly or implicitly) a `deopt` block successor,
and it is always legal to go there no matter what the guard condition is. The other successor is
a guarded block, and it is only legal to go there if the condition is true.

This patch introduces a new explicit form of guards alternative to `@llvm.experimental.guard`
intrinsic. Now a widenable guard can be represented in the CFG explicitly like this:

    %widenable_condition = call i1 @llvm.experimental.widenable.condition()
    %new_condition = and i1 %cond, %widenable_condition
    br i1 %new_condition, label %guarded, label %deopt

  guarded:
    ; Guarded instructions

  deopt:
    call type @llvm.experimental.deoptimize(<args...>) [ "deopt"(<deopt_args...>) ]

The new intrinsic `@llvm.experimental.widenable.condition` has semantics of an
`undef`, but the intrinsic prevents the optimizer from folding it early. This form
should exploit all optimization boons provided to `br` instuction, and it still can be
widened by replacing the result of `@llvm.experimental.widenable.condition()`
with `and` with any arbitrary boolean value (as long as the branch that is taken when
it is `false` has a deopt and has no side-effects).

For more motivation, please check llvm-dev discussion "[llvm-dev] Giving up using
implicit control flow in guards".

This patch introduces this new intrinsic with respective LangRef changes and a pass
that converts old-style guards (expressed as intrinsics) into the new form.

The naming discussion is still ungoing. Merging this to unblock further items. We can
later change the name of this intrinsic.

Reviewed By: reames, fedor.sergeev, sanjoy
Differential Revision: https://reviews.llvm.org/D51207

llvm-svn: 348593

Introduce ObjectFileBreakpad

Summary:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information

A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +

Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).

In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.

Reviewers: clayborg, zturner, lemo, amccarth

Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits

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

llvm-svn: 348592

ARM: use correct offset from base pointer (r6) in call frame regions.

When we had dynamic call frames (i.e. sp adjustment around each call) we
were including that adjustment into offsets calculated based on r6, even
though it's only sp that changes. This led to incorrect stack slot
accesses.

llvm-svn: 348591

[CodeComplete] Fix assertion failure

Summary:
...that fires when running completion inside an argument of
UnresolvedMemberExpr (see the added test).

The assertion that fires is from Sema::TryObjectArgumentInitialization:

    assert(FromClassification.isLValue());

This happens because Sema::AddFunctionCandidates does not account for
object types which are pointers. It ends up classifying them incorrectly.
All usages of the function outside code completion are used to run
overload resolution for operators. In those cases the object type being
passed is always a non-pointer type, so it's not surprising the function
did not expect a pointer in the object argument.

However, code completion reuses the same function and calls it with the
object argument coming from UnresolvedMemberExpr, which can be a pointer
if the member expr is an arrow ('->') access.

Extending AddFunctionCandidates to allow pointer object types does not
seem too crazy since all the functions down the call chain can properly
handle pointer object types if we properly classify the object argument
as an l-value, i.e. the classification of the implicitly dereferenced
pointer.

Reviewers: kadircet

Reviewed By: kadircet

Subscribers: cfe-commits

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

llvm-svn: 348590

[unittests] Merge the PrintedStmtCXX..Matches functions (NFC)

This was reviewed as part of https://reviews.llvm.org/D36527

llvm-svn: 348589

Adding tests for -ast-dump; NFC.

This adds tests for various statements in C.

llvm-svn: 348588

[CTU] Eliminate race condition in CTU lit tests

Summary:
We plan to introduce additional CTU related lit test. Since lit may run the
tests in parallel, it is not safe to use the same directory (%T) for these
tests. It is safe to use however test case specific directories (%t).

Reviewers: xazax.hun, a_sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

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

llvm-svn: 348587

[CTU] Add asserts to protect invariants

Reviewers: xazax.hun, a_sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

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

llvm-svn: 348586

[Targets] Add errors for tiny and kernel codemodel on targets that don't support them

Adds fatal errors for any target that does not support the Tiny or Kernel
codemodels by rejigging the getEffectiveCodeModel calls.

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

llvm-svn: 348585

[CTU] Add statistics

Reviewers: xazax.hun, a_sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

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

llvm-svn: 348584

[clang-tidy] Remove duplicated getText implementation, NFC

llvm-svn: 348583

Add a AArch64 triple to tiny codemodel test.

Most other targets do not support the tiny code model.

llvm-svn: 348582

Fix gcc7.3 -Wparentheses warning. NFCI.

llvm-svn: 348581

[yaml2obj] format some codes NFC.

Summary: This line is longer than 80 characters.

Subscribers: llvm-commits, jakehehrlich

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

llvm-svn: 348580

[yaml2obj] revert bad change

llvm-svn: 348579

[yaml2obj] format some codes NFC.

Summary: This line is longer than 80 characters.

Subscribers: llvm-commits, jakehehrlich

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

llvm-svn: 348578

Fix test/tools/llvm-mca/AArch64/Exynos/direct-branch.s on Mac

It was failing as below. Adding a triple seems to help.

--
: 'RUN: at line 2';   /work/llvm.combined/build.release/bin/llvm-mca -march=aarch64 -mcpu=exynos-m1 -resource-pressure=false < /work/llvm.combined/llvm/test/tools/llvm-mca/AArch64/Exynos/direct-branch.s | /work/llvm.combined/build.release/bin/FileCheck /work/llvm.combined/llvm/test/tools/llvm-mca/AArch64/Exynos/direct-branch.s -check-prefixes=ALL,M1
: 'RUN: at line 3';   /work/llvm.combined/build.release/bin/llvm-mca -march=aarch64 -mcpu=exynos-m3 -resource-pressure=false < /work/llvm.combined/llvm/test/tools/llvm-mca/AArch64/Exynos/direct-branch.s | /work/llvm.combined/build.release/bin/FileCheck /work/llvm.combined/llvm/test/tools/llvm-mca/AArch64/Exynos/direct-branch.s -check-prefixes=ALL,M3
--
Exit Code: 1

Command Output (stderr):
--
/work/llvm.combined/llvm/test/tools/llvm-mca/AArch64/Exynos/direct-branch.s:36:12: error: M1-NEXT: expected string not found in input
           ^
<stdin>:21:2: note: scanning from here
 1 0 0.25 b Ltmp0
 ^

--

llvm-svn: 348577

[utils] Use operator "in" instead of bound function "has_key"

has_key has been removed in Python 3. The in comparison operator can be used
instead.

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

llvm-svn: 348576

[X86] Add ivybridge to llvm-exegesis PFM counter mappings

llvm-svn: 348575

[SelectionDAG] Don't pass on DemandedElts when handling SCALAR_TO_VECTOR

Fixes an assertion:

llc: lib/CodeGen/SelectionDAG/SelectionDAG.cpp:2200: llvm::KnownBits llvm::SelectionDAG::computeKnownBits(llvm::SDValue, const llvm::APInt&, unsigned int) const: Assertion `(!Op.getValueType().isVector() || NumElts == Op.getValueType().getVectorNumElements()) && "Unexpected vector size"' failed.

Committed on behalf of: @pendingchaos (Rhys Perry)

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

llvm-svn: 348574

[CMake] Add support for NO_INSTALL_RPATH argument in llvm_add_library()

Summary:
Allow clients to suppress setup of default RPATHs in designated library targets. This is used in LLDB when emitting liblldb as a framework bundle, which itself doesn't load further RPATH-dependent libraries.
This follows the approach in add_llvm_executable().

Reviewers: aprantl, JDevlieghere, davide, friss

Reviewed By: aprantl

Subscribers: mgorny, lldb-commits, llvm-commits, #lldb

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

llvm-svn: 348573

[PowerPC] VSX register support for inline assembly

Summary:
The patch is to add the VSX register support for inline assembly. After this
patch, we can use VSX register in inline assembly clobber list without error.

Reviewed By: jsji,  nemanjai

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

llvm-svn: 348572

[IR] Don't assume all functions are 4 byte aligned

In some cases different alignments for function might be used to save
space e.g. thumb mode with -Oz will try to use 2 byte function
alignment. Similar patch that fixed this in other areas exists here
https://reviews.llvm.org/D46110

This was approved previously https://reviews.llvm.org/D55115 (r348215)
but when committed it caused failures on the sanitizer buildbots when
building llvm with clang (containing this patch). This is now fixed
because I've added a check to see if getting the parent module returns
null if it does then set the alignment to 0.

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

llvm-svn: 348571

[PM] Port LoadStoreVectorizer to the new pass manager.

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

llvm-svn: 348570

Fix thunks returning memptrs via sret by emitting also scalar return values directly in sret slot (PR39901)

Thunks that return member pointers via sret are broken due to using temporary
storage for the return value on the stack and then passing that pointer to a
tail call, violating the rule that a tail call can't access allocas in the
caller (see bug).

Since r90526, we put aggregate return values directly in the sret slot, but
this doesn't apply to member pointers which are considered scalar.

Unless I'm missing something subtle, we should be able to always use the sret
slot directly for indirect return values.

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

llvm-svn: 348569

[XRay] Use preallocated memory for XRay profiling

Summary:
This change builds upon D54989, which removes memory allocation from the
critical path of the profiling implementation. This also changes the API
for the profile collection service, to take ownership of the memory and
associated data structures per-thread.

The consolidation of the memory allocation allows us to do two things:

- Limits the amount of memory used by the profiling implementation,
  associating preallocated buffers instead of allocating memory
  on-demand.

- Consolidate the memory initialisation and cleanup by relying on the
  buffer queue's reference counting implementation.

We find a number of places which also display some problematic
behaviour, including:

- Off-by-factor bug in the allocator implementation.

- Unrolling semantics in cases of "memory exhausted" situations, when
  managing the state of the function call trie.

We also add a few test cases which verify our understanding of the
behaviour of the system, with important edge-cases (especially for
memory-exhausted cases) in the segmented array and profile collector
unit tests.

Depends on D54989.

Reviewers: mboerger

Subscribers: dschuff, mgorny, dmgreen, jfb, llvm-commits

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

llvm-svn: 348568

[LoopSimplifyCFG] Do not deal with loops with irreducible CFG inside

The current algorithm that collects live/dead/inloop blocks relies on some invariants
related to RPO and PO traversals. In particular, the important fact it requires is that
the only loop's latch is the first block in PO traversal. It also relies on fact that during
RPO we visit all prececessors of a block before we visit this block (backedges ignored).

If a loop has irreducible non-loop cycle inside, both these assumptions may break.
This patch adds detection for this situation and prohibits the terminator folding
for loops with irreducible CFG.

We can in theory support this later, for this some algorithmic changes are needed.
Besides, irreducible CFG is not a frequent situation and we can just don't bother.

Thanks @uabelho for finding this!

Differential Revision: https://reviews.llvm.org/D55357
Reviewed By: skatkov

llvm-svn: 348567

[PowerPC] Fix assert from machine verify pass that missing undef register flag

Fix assert about using an undefined physical register in machine instruction verify pass.
The reason is that register flag undef is missing when doing transformation from If Conversion Pass.

```
Bad machine code: Using an undefined physical register
- function:    func_65
- basic block: %bb.0 entry (0x10024740738)
- instruction: BCLR killed $cr5lt, implicit $lr8, implicit $rm, implicit undef $x3
- operand 0:   killed $cr5lt
LLVM ERROR: Found 1 machine code errors.
```

There are also other existing testcases with same issue. So I add -verify-machineinstrs option to open verifying.

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

llvm-svn: 348566

[llvm-mca] Improve test (NFC)

Add more instructions to the test for Cortex.

llvm-svn: 348565

[llvm-mca] Improve test (NFC)

Add a label to make explicit that the branch is short for Exynos.

llvm-svn: 348564

Re-land "[XRay] Move-only Allocator, FunctionCallTrie, and Array"

This reverts commit r348455, with some additional changes:

- Work-around deficiency of gcc-4.8 by duplicating the implementation of
  `AppendEmplace` in `Append`, but instead of using brace-init for the
  copy construction, use a placement new explicitly calling the copy
  constructor.

llvm-svn: 348563

[CodeExtractor] Store outputs at the first valid insertion point

When CodeExtractor outlines values which are used by the original
function, it must store those values in some in-out parameter. This
store instruction must not be inserted in between a PHI and an EH pad
instruction, as that results in invalid IR.

This fixes the following verifier failure seen while outlining within
ObjC methods with live exit values:

  The unwind destination does not have an exception handling instruction!
    %call35 = invoke i8* bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to i8* (i8*, i8*)*)(i8* %exn.adjusted, i8* %1)
            to label %invoke.cont34 unwind label %lpad33, !dbg !4183
  The unwind destination does not have an exception handling instruction!
    invoke void @objc_exception_throw(i8* %call35) #12
            to label %invoke.cont36 unwind label %lpad33, !dbg !4184
  LandingPadInst not the first non-PHI instruction in the block.
    %3 = landingpad { i8*, i32 }
            catch i8* null, !dbg !1411

rdar://46540815

llvm-svn: 348562

Add SBInitializerOptions.h to the Xcode project.

And mark it as a public header so it will get copied
into the LLDB.framework.  A handful of "api" tests were
failing because they couldn't find this file.

llvm-svn: 348561

Revert "[llvm-tapi] Don't override SequenceTraits for std::string"

Revert r348551 since it triggered some warnings that don't appear to have a quick fix.

llvm-svn: 348560

Handle detecting exec for DynamicLoaderMacOS with older debugservers
that don't send reason:exec.

<rdar://problem/43756823>

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

llvm-svn: 348559

Revert "[DemandedBits][BDCE] Support vectors of integers"

This reverts commit r348549. Causing assertion failures during
clang build.

llvm-svn: 348558

Change the amount of data that Platform::PutFile will try to transfer
in one packet from 1k bytes to 16k bytes.  Sending a large file to an
iOS device directly connected by USB cable, to lldb-server running in
platform mode, this speeds up the file xfer by 77%.  Sending the file
in 32k blocks speeds up the file xfer by 80% versus 1k blocks, starting
with 16k to make sure we don't have any problems with android testing.

We may not have the same perf characteristics over ethernet, but with
USB it's faster to send fewer larger packets than many small packets.

llvm-svn: 348557

Host: remove Yield on Windows

Windows provides a Yield function-like macro that allows a thread to
yield the CPU.  However, this conflicts with `Yield` in swift.  Undefine
`Yield` to allow building lldb with swift support.

llvm-svn: 348556

Add test for InitListExpr

llvm-svn: 348553

[DAGCombiner] use root SDLoc for all nodes created by logic fold

If this is not a valid way to assign an SDLoc, then we get this
wrong all over SDAG.

I don't know enough about the SDAG to explain this. IIUC, theoretically,
debug info is not supposed to affect codegen. But here it has clearly
affected 3 different targets, and the x86 change is an actual improvement.

llvm-svn: 348552

[llvm-tapi] Don't override SequenceTraits for std::string

Change the ELF YAML implementation of TextAPI so NeededLibs uses flow
sequence vector correctly instead of overriding the YAML implementation
for std::vector<std::string>>.

This should fix the test failure with the LLVM_LINK_LLVM_DYLIB build mentioned in D55381.

Still passes existing tests that cover this.

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

llvm-svn: 348551

[DAGCombiner] don't bother saving a SDLoc for a node that's dead; NFCI

We shouldn't care about the debug location for a node that
we're creating, but attaching the root of the pattern should
be the best effort. (If this is not true, then we are doing
it wrong all over the SDAG).

This is no-functional-change-intended, and there are no
regression test diffs...and that's what I expected. But
there's a similar line above this diff, where those
assumptions apparently do not hold.

llvm-svn: 348550

[DemandedBits][BDCE] Support vectors of integers

DemandedBits and BDCE currently only support scalar integers. This
patch extends them to also handle vector integer operations. In this
case bits are not tracked for individual vector elements, instead a
bit is demanded if it is demanded for any of the elements. This matches
the behavior of computeKnownBits in ValueTracking and
SimplifyDemandedBits in InstCombine.

The getDemandedBits() method can now only be called on instructions that
have integer or vector of integer type. Previously it could be called on
any sized instruction (even if it was not particularly useful). The size
of the return value is now always the scalar size in bits (while
previously it was the type size in bits).

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

llvm-svn: 348549

[BDCE] Add tests for BDCE applied to vector instructions; NFC

These are baseline tests for D55297.

llvm-svn: 348548

[DAGCombiner] more clean up in hoistLogicOpWithSameOpcodeHands(); NFC

This code can still misbehave.

llvm-svn: 348547

NFC: Move VisitExpr code to dumpStmt

Summary:
The call is duplicated in the handlers of all Expr subclasses.

This change makes it easy to split statement handling out to
TextNodeDumper.

Reviewers: aaron.ballman

Subscribers: cfe-commits

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

llvm-svn: 348546

NFC: Move VisitStmt code to dumpStmt

Summary: This call is duplicated in Visits of all direct subclasses of Stmt.

Reviewers: aaron.ballman

Subscribers: cfe-commits

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

llvm-svn: 348545

[lit] Use the build.py script in the case-insensitive test

This makes the test build correctly regardless of whether we use VS or ninja to run the tests

llvm-svn: 348544

Add more expected content to match in test

llvm-svn: 348543

[pecoff] Use PATH_MAX instead of MAX_PATH

PATH_MAX is defined on all platforms while MAX_PATH is Windows-specific

llvm-svn: 348542

Use relative line offsets in test

llvm-svn: 348541

[frontend][darwin] warn_stdlibcxx_not_found: supress warning for preprocessed input

Addresses second post-commit feedback for r335081 from Nico

llvm-svn: 348540

Run `git ls-files '*.gn' '*.gni' | xargs -n 1 gn format`.

llvm-svn: 348539

[gn build] merge r348505.

llvm-svn: 348537

[X86] Directly create ADC/SBB nodes instead of using ADD/SUB with (and SETCC_CARRY, 1)

This addresses a FIXME and avoids depending on an isel pattern match I think. I've remove the isel patterns too since he have no lit tests left that cover them. Hopefully that really means they are unused.

I'm trying to decide if we need SETCC_CARRY. This removes one of its usages.

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

llvm-svn: 348536

[DAGCombiner] don't group bswap with casts in logic hoisting fold

This was probably organized as it was because bswap is a unary op.
But that's where the similarity to the other opcodes ends. We should
not limit this transform to scalars, and we should not try it if
either input has other uses. This is another step towards trying to
clean this whole function up to prevent it from causing infinite loops
and memory explosions.

Earlier commits in this series:
rL348501
rL348508
rL348518

llvm-svn: 348534

[analyzer] Rely on os_consumes_this attribute to signify that the method call consumes a reference for "this"

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

llvm-svn: 348533

[attributes] Add an attribute os_consumes_this, with similar semantics to ns_consumes_self

The attribute specifies that the call of the C++ method consumes a
reference to "this".

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

llvm-svn: 348532

[analyzer] Fix an infinite recursion bug while checking parent methods in RetainCountChecker

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

llvm-svn: 348531

[x86] add test for vector bitwise-logic-of-bswaps; NFC

llvm-svn: 348530

[libc++] Improve diagnostics for non-const comparators and hashers in associative containers

Summary:
When providing a non-const-callable comparator in a map or set, the
warning diagnostic does not include the point of instantiation of
the container that triggered the warning, which makes it difficult
to track down the problem. This commit improves the diagnostic by
placing it directly in the body of the associative container.

The same change is applied to unordered associative containers, which
had a similar problem.

Finally, this commit cleans up the forward declarations of several
map and unordered_map helpers, which are not needed anymore.

<rdar://problem/41370747>

Reviewers: EricWF, mclow.lists

Subscribers: christof, dexonsmith, llvm-commits

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

llvm-svn: 348529

[pecoff] Implement ObjectFilePECOFF::GetDependedModules()

Summary:
This parses entries in pecoff import tables for imported DLLs and
is intended as the first step to allow LLDB to load a PE's shared
modules when creating a target on the LLDB console.

Reviewers: rnk, zturner, aleksandr.urakov, lldb-commits, labath, asmith

Reviewed By: labath, asmith

Subscribers: labath, lemo, clayborg, Hui, mgorny, mgrang, teemperor

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

llvm-svn: 348527

Implement WindowsDYLD::DidAttach for use with gdb-server attach

Summary:
Windows lldb debugging currently uses a process plugin to handle
launching and attaching to a process. Launching a process via a debug
server (e.g. ds2) and attaching to it with `gdb-remote port` currently
doesn't communicate address information of the executable properly.

Implement DynamicLoaderWindowsDYLD::DidAttach which allow us to
obtain the proper executable load address.

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

llvm-svn: 348526

[libcxx] Always convert 'use_system_cxx_lib' to an absolute path

Otherwise, some tests would fail when a relative path was passed,
because they'd use the relative path from a different directory
than the current working directory.

llvm-svn: 348525

[test] Add missing cmake include for building libFuzzer alone

Include CompilerRTCompile in fuzzer tests explicitly.  Otherwise, when
building only libFuzzer, CMake fails due to:

CMake Error at cmake/Modules/AddCompilerRT.cmake:395 (sanitizer_test_compile):
  Unknown CMake command "sanitizer_test_compile".
Call Stack (most recent call first):
  lib/fuzzer/tests/CMakeLists.txt:53 (generate_compiler_rt_tests)

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

llvm-svn: 348524

[DAGCombiner] reduce indent; NFC

Unlike some of the folds in hoistLogicOpWithSameOpcodeHands()
above this shuffle transform, this has the expected hasOneUse()
checks in place.

llvm-svn: 348523

[DagCombiner][X86] Simplify a ConcatVectors of a scalar_to_vector with undef.

This patch introduces a new DAGCombiner rule to simplify concat_vectors nodes:

concat_vectors( bitcast (scalar_to_vector %A), UNDEF)
    --> bitcast (scalar_to_vector %A)

This patch only partially addresses PR39257. In particular, it is enough to fix
one of the two problematic cases mentioned in PR39257. However, it is not enough
to fix the original test case posted by Craig; that particular case would
probably require a more complicated approach (and knowledge about used bits).

Before this patch, we used to generate the following code for function PR39257
(-mtriple=x86_64 , -mattr=+avx):

vmovsd  (%rdi), %xmm0           # xmm0 = mem[0],zero
vxorps  %xmm1, %xmm1, %xmm1
vblendps        $3, %xmm0, %xmm1, %xmm0 # xmm0 = xmm0[0,1],xmm1[2,3]
vmovaps %ymm0, (%rsi)
vzeroupper
retq

Now we generate this:

vmovsd  (%rdi), %xmm0           # xmm0 = mem[0],zero
vmovaps %ymm0, (%rsi)
vzeroupper
retq

As a side note: that VZEROUPPER is completely redundant...

I guess the vzeroupper insertion pass doesn't realize that the definition of
%xmm0 from vmovsd is already zeroing the upper half of %ymm0. Note that on
%-mcpu=btver2, we don't get that vzeroupper because pass vzeroupper insertion
%pass is disabled.

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

llvm-svn: 348522

[OPENMP][NVPTX]Correct type casting for printf args + simplified shfl64 function.

Summary:
Explicitly casted printf's args to the required types + simplified
shfl64 function.

Reviewers: gtbercea, kkwli0

Subscribers: guansong, jfb, caomhin, openmp-commits

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

llvm-svn: 348521

[libcxx] Fix incorrect XFAILs for chrono tests on old macos deployment targets

The tests were marked to fail based on the 'availability' LIT feature.
However, those tests should really only be failing when we run them
against the dylibs that were deployed on macosx10.7 and macosx10.8,
which the deployment target has nothing to do with.

This caused the tests to unexpectedly pass when running the tests
with deployment target macosx10.{7,8} but running with a recent dylib.

llvm-svn: 348520

Fix the Xcode project build for the addition of NativePDB/DWARFLocationExpression.{h,cpp}

llvm-svn: 348519

[DAGCombiner] don't hoist logic op if operands have other uses, part 2

The PPC test with 2 extra uses seems clearly better by avoiding this transform.
With 1 extra use, we also prevent an extra register move (although that might
be an RA problem). The general rule should be to only make a change here if
it is always profitable. The x86 diffs are all neutral.

llvm-svn: 348518

Fix Wdocumentation warning. NFCI.

llvm-svn: 348517

[PowerPC] add tests for hoisting bitwise logic; NFC

llvm-svn: 348516

Allow forwarding -fdebug-compilation-dir to cc1as

The flag -fdebug-compilation-dir is useful to make generated .o files
independent of the path of the build directory, without making the compile
command-line dependent on the path of the build directory, like
-fdebug-prefix-map requires. This change makes it so that the driver can
forward the flag to -cc1as, like it already can for -cc1. We might want to
consider making -fdebug-compilation-dir a driver flag in a follow-up.

(Since -fdebug-compilation-dir defaults to PWD, it's already possible to get
this effect by setting PWD, but explicit compiler flags are better than env
vars, because e.g. ninja tracks command lines and reruns commands that change.)

Somewhat related to PR14625.

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

llvm-svn: 348515

Fix line endings in build.py

llvm-svn: 348514

Reapply "Avoid emitting redundant or unusable directories in DIFile metadata entries.""

This reverts commit r348280 and reapplies D55085 without modifications.

Original commit message:

    Avoid emitting redundant or unusable directories in DIFile metadata entries.

    As discussed on llvm-dev recently, Clang currently emits redundant
    directories in DIFile entries, such as

      .file      1 "/Volumes/Data/llvm" "/Volumes/Data/llvm/tools/clang/test/CodeGen/debug-info-abspath.c"

    This patch looks at any common prefix between the compilation
    directory and the (absolute) file path and strips the redundant
    part. More importantly it leaves the compilation directory empty if
    the two paths have no common prefix.

    After this patch the above entry is (assuming a compilation dir of "/Volumes/Data/llvm/_build"):

      .file 1 "/Volumes/Data/llvm" "tools/clang/test/CodeGen/debug-info-abspath.c"

    When building the FileCheck binary with debug info, this patch makes
    the build artifacts ~1kb smaller.

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

llvm-svn: 348513

Reapply "Adapt gcov to changes in CFE."

This reverts commit r348203 and reapplies D55085 with an additional
GCOV bugfix to make the change NFC for relative file paths in .gcno files.

Thanks to Ilya Biryukov for additional testing!

Original commit message:

    Update Diagnostic handling for changes in CFE.

    The clang frontend no longer emits the current working directory for
    DIFiles containing an absolute path in the filename: and will move the
    common prefix between current working directory and the file into the
    directory: component.

    https://reviews.llvm.org/D55085

llvm-svn: 348512

[build.py] Embed the output file name in generated object file names.

In compile-and-link mode, the user doesn't specify the name of the
object files to generate, because there could be multiple inputs
on a single command line and this would be hard to specify.  So the
script just tries to be smart and figure out the best object file
names.  However, if two build scripts are running in parallel and
using the same source files as input, they would previously race
to write the same object files, since the computed name only considered
the source file names when computing the object file names.

With this patch, we also consider the final executable name.  In a
way, this "namespaces" the generated object files so that as long
as the final executable file names don't clash, the intermediate
object file names won't clash either.

llvm-svn: 348511