[CUDA] Add option to generate relocatable device code

As a first step, pass '-c/--compile-only' to ptxas so that it
doesn't complain about references to external function. This
will successfully generate object files, but they won't work
at runtime because the registration routines need to adapted.

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

llvm-svn: 324878

[CUDA] Fix test cuda-external-tools.cu

This didn't verify the CHECK prefix before!

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

llvm-svn: 324877

[gtest] Support raw_ostream printing functions more comprehensively.

Summary:
These are functions like operator<<(raw_ostream&, Foo).

Previously these were only supported for messages. In the assertion
  EXPECT_EQ(A, B) << C;
the local modifications would explicitly try to use raw_ostream printing for C.
However A and B would look for a std::ostream printing function, and often fall
back to gtest's default "168 byte object <00 01 FE 42 ...>".

This patch pulls out the raw_ostream support into a new header under `custom/`.

I changed the mechanism: instead of a convertible stream, we wrap the printed
value in a proxy object to allow it to be sent to a std::ostream.
I think the new way is clearer.

I also changed the policy: we prefer raw_ostream printers over std::ostream
ones. This is because the fallback printers are defined using std::ostream,
while all the raw_ostream printers should be "good".

Reviewers: ilya-biryukov, chandlerc

Subscribers: llvm-commits

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

llvm-svn: 324876

Skip TestTargetXMLArch on non-darwin OSs

This test uses XML packets, but libxml is an optional dependency of
lldb, and this test fails if it is not present.

I'm leaving this enabled on mac, as thats the only platform that's
likely to have libxml always available, but ideally we should have a way
to skip this based on build configuration. I'll see if I can whip
something like that up soon, but for the time being, this unblocks the
buildbots.

llvm-svn: 324870

[mips] Fix 'l' constraint handling for types smaller than 32 bits

In case of correct using of the 'l' constraint llvm now generates valid
code; otherwise it shows an error message. Initially these triggers an
assertion.

llvm-svn: 324869

[MC] Issue error message when data region is not terminated

llvm-svn: 324868

[NFC] Fix typos

llvm-svn: 324867

[SCEV] Make getPostIncExpr guaranteed to return AddRec

The current implementation of `getPostIncExpr` invokes `getAddExpr` for two recurrencies
and expects that it always returns it a recurrency. But this is not guaranteed to happen if we
have reached max recursion depth or refused to make SCEV simplification for other reasons.

This patch changes its implementation so that now it always returns SCEVAddRec without
relying on `getAddExpr`.

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

llvm-svn: 324866

[X86] Don't look for TEST instruction shrinking opportunities when the root node is a X86ISD::SUB.

I don't believe we ever create an X86ISD::SUB with a 0 constant which is what the TEST handling needs. The ternary operator at the end of this code shows up as only going one way in the llvm-cov report from the bots.

llvm-svn: 324865

[X86] Remove check for X86ISD::AND with no flag users from the TEST instruction immediate shrinking code.

We turn X86ISD::AND with no flag users back to ISD::AND in PreprocessISelDAG.

llvm-svn: 324864

[X86] Change some compare patterns to use loadi8/loadi16/loadi32/loadi64 helper fragments.

This enables CMP8mi to fold zextloadi8i1 which in all tests allows us to avoid creating a TEST8rr that peephole can't fold.

llvm-svn: 324863

[X86] Autogenerate complete checks. NFC

llvm-svn: 324862

[X86] Add KADD X86ISD opcode instead of reusing ISD::ADD.

ISD::ADD implies individual vector element addition with no carries between elements. But for a vXi1 type that would be the same as XOR. And we already turn ISD::ADD into ISD::XOR for all vXi1 types during lowering. So the ISD::ADD pattern would never be able to match anyway.

KADD is different, it adds the elements but also propagates a carry between them. This just a way of doing an add in k-register without bitcasting to the scalar domain. There's still no way to match the pattern, but at least its not obviously wrong.

llvm-svn: 324861

[X86] Allow zextload/extload i1->i8 to be folded into instructions during isel

Previously we just emitted this as a MOV8rm which would likely get folded during the peephole pass anyway. This just makes it explicit earlier.

The gpr-to-mask.ll test changed because the kaddb instruction has no memory form.

llvm-svn: 324860

Follow on to rL324854 (Added tests)

llvm-svn: 324859

[X86] Remove MASK_BINOP intrinsic type. NFC

llvm-svn: 324858

[X86] Remove dead code from getMaskNode that looked for a i64 mask with a maskVT that wasn't v64i1. NFC

llvm-svn: 324857

[X86] Remove LowerBoolVSETCC_AVX512, we get this with a target independent DAG combine now. NFC

llvm-svn: 324856

Add default C++ ABI libname and include paths for FreeBSD

Summary:
As noted in a discussion about testing the LLVM 6.0.0 release candidates
(with libc++) for FreeBSD, many tests turned out to fail with
"exception_ptr not yet implemented".  This was because libc++ did not
choose the correct C++ ABI library, and therefore it fell back to the
`exception_fallback.ipp` header.

Since FreeBSD 10.x, we have been using libcxxrt as our C++ ABI library,
and its headers have always been installed in /usr/include/c++/v1,
together with the (system) libc++ headers.  (Older versions of FreeBSD
used GNU libsupc++ by default, but these are now unsupported.)

Therefore, if we are building libc++ for FreeBSD, set:
* `LIBCXX_CXX_ABI_LIBNAME` to "libcxxrt"
* `LIBCXX_CXX_ABI_INCLUDE_PATHS` to "/usr/include/c++/v1"
by default.

Reviewers: emaste, EricWF, mclow.lists

Reviewed By: EricWF

Subscribers: mgorny, cfe-commits, krytarowski

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

llvm-svn: 324855

[ThinLTO] Add GraphTraits for FunctionSummaries

Add GraphTraits definitions to the FunctionSummary and ModuleSummaryIndex classes. These GraphTraits will be used to construct find SCC's in ThinLTO analysis passes.

llvm-svn: 324854

Fix libcxx MSVC C++17 redefinition of 'align_val_t'

Patch from  charlieio@outlook.com

Reviewed as https://reviews.llvm.org/D42354

When the following command is used:

> clang-cl -std:c++17 -Iinclude\c++\v1 hello.cc c++.lib

An error occurred:

In file included from hello.cc:1:
In file included from include\c++\v1\iostream:38:
In file included from include\c++\v1\ios:216:
In file included from include\c++\v1\__locale:15:
In file included from include\c++\v1\string:477:
In file included from include\c++\v1\string_view:176:
In file included from include\c++\v1\__string:56:
In file included from include\c++\v1\algorithm:643:
In file included from include\c++\v1\memory:656:
include\c++\v1\new(165,29):  error: redefinition of 'align_val_t'
enum class _LIBCPP_ENUM_VIS align_val_t : size_t { };
                            ^
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\include\vcruntime_new.h(43,16):  note:
      previous definition is here
    enum class align_val_t : size_t {};
               ^
1 error generated.
vcruntime_new.h has defined align_val_t, libcxx need hide align_val_t.

This patch fixes that error.

llvm-svn: 324853

Mark two issues as complete

llvm-svn: 324852

Fix a typo in the synopsis comment. NFC. Thanks to K-ballo for the catch

llvm-svn: 324851

[CodeView] Allow variable names to be as long as the codeview format supports

Instead of reserving 0xF00 bytes for the fixed length portion of the CodeView
symbol name, calculate the actual length of the fixed length portion.

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

llvm-svn: 324850

Revert r324847, there's bot failures.

llvm-svn: 324849

[sanitizer] Implement NanoTime() on Darwin

Currently NanoTime() on Darwin is unimplemented and always returns 0. Looks like there's quite a few things broken because of that (TSan periodic memory flush, ASan allocator releasing pages back to the OS). Let's fix that.

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

llvm-svn: 324847

[compiler-rt] Replace forkpty with posix_spawn

On Darwin, we currently use forkpty to communicate with the "atos" symbolizer. There are several problems that fork or forkpty has, e.g. that after fork, interceptors are still active and this sometimes causes crashes or hangs. This is especially problematic for TSan, which uses interceptors for OS-provided locks and mutexes, and even Libc functions use those.

This patch replaces forkpty with posix_spawn. Since posix_spawn doesn't fork (at least on Darwin), the interceptors are not a problem. Additionally, this also fixes a latent threading problem with ptsname (it's unsafe to use this function in multithreaded programs). Yet another benefit is that we'll handle post-fork failures (e.g. sandbox disallows "exec") gracefully now.

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

llvm-svn: 324846

[X86] Update some required-vector-width.ll test cases to not pass 512-bit vectors in arguments or return.

ABI for these would require 512 bits support so we don't want to test that.

llvm-svn: 324845

[X86][SSE] Use SplitBinaryOpsAndApply to recognise PSUBUS patterns before they're split on AVX1

This needs to be generalised further to support AVX512BW cases but I want to add non-uniform constants first.

llvm-svn: 324844

[InstCombine] X / (X * Y) -> 1 / Y if the multiplication does not overflow

The related cases for (X * Y) / X were handled in rL124487.

https://rise4fun.com/Alive/6k9

The division in these tests is subsequently eliminated by existing instcombines
for 1/X.

llvm-svn: 324843

[X86] Use min/max for vector ult/ugt compares if avoids a sign flip.

Summary:
Currently we only use min/max to help with ule/uge compares because it removes an invert of the result that would otherwise be needed. But we can also use it for ult/ugt compares if it will prevent the need for a sign bit flip needed to use pcmpgt at the cost of requiring an invert after the compare.

I also refactored the code so that the max/min code is self contained and does its own return instead of setting up a flag to manipulate the rest of the function's behavior.

Most of the test cases look ok with this. I did notice that we added instructions when one of the operands being sign flipped is a constant vector that we were able to constant fold the flip into.

I also noticed that sometimes the SSE min/max clobbers a register that is needed after the compare. This resulted in an extra move being inserted before the min/max to preserve the register. We could try to detect this and switch from min to max and change the compare operands to use the operand that gets reused in the compare.

Reviewers: spatel, RKSimon

Reviewed By: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 324842

[X86][SSE] Moved SplitBinaryOpsAndApply earlier so more methods can use it. NFCI.

llvm-svn: 324841

[InstCombine] add tests for div-mul folds; NFC

The related cases for (X * Y) / X were handled in rL124487.

llvm-svn: 324840

[TargetLowering] try to create -1 constant operand for math ops via demanded bits

This reverses instcombine's demanded bits' transform which always tries to clear bits in constants.

As noted in PR35792 and shown in the test diffs:
https://bugs.llvm.org/show_bug.cgi?id=35792
...we can do better in codegen by trying to form -1. The x86 sub test shows a missed opportunity.

I did investigate changing instcombine's behavior, but it would be more work to change
canonicalization in IR. Clearing bits / shrinking constants can allow killing instructions,
so we'd have to figure out how to not regress those cases.

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

llvm-svn: 324839

[X86] Add PR33747 test case

llvm-svn: 324838

[X86][SSE] Enable SMIN/SMAX/UMIN/UMAX custom lowering for all legal types

This allows us to recognise more saturation patterns and also simplify some MINMAX codegen that was failing to combine CMPGE comparisons to a legal CMPGT.

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

llvm-svn: 324837

fix test/CodeGen/X86/fixup-sfb.ll test failure after commit https://reviews.llvm.org/rL324835

Change-Id: I2526c2f342654e85ce054237de03ae9db9ab4994
llvm-svn: 324836

[X86] Reduce Store Forward Block issues in HW

If a load follows a store and reloads data that the store has written to memory, Intel microarchitectures can in many cases forward the data directly from the store to the load, This "store forwarding" saves cycles by enabling the load to directly obtain the data instead of accessing the data from cache or memory.
A "store forward block" occurs in cases that a store cannot be forwarded to the load. The most typical case of store forward block on Intel Core microarchiticutre that a small store cannot be forwarded to a large load.
The estimated penalty for a store forward block is ~13 cycles.

This pass tries to recognize and handle cases where "store forward block" is created by the compiler when lowering memcpy calls to a sequence
of a load and a store.

The pass currently only handles cases where memcpy is lowered to XMM/YMM registers, it tries to break the memcpy into smaller copies.
breaking the memcpy should be possible since there is no atomicity guarantee for loads and stores to XMM/YMM.

Change-Id: I620b6dc91583ad9a1444591e3ddc00dd25d81748
llvm-svn: 324835

[X86] Don't make 512-bit vectors legal when preferred vector width is 256 bits and 512 bits aren't required

This patch adds a new function attribute "required-vector-width" that can be set by the frontend to indicate the maximum vector width present in the original source code. The idea is that this would be set based on ABI requirements, intrinsics or explicit vector types being used, maybe simd pragmas, etc. The backend will then use this information to determine if its save to make 512-bit vectors illegal when the preference is for 256-bit vectors.

For code that has no vectors in it originally and only get vectors through the loop and slp vectorizers this allows us to generate code largely similar to our AVX2 only output while still enabling AVX512 features like mask registers and gather/scatter. The loop vectorizer doesn't always obey TTI and will create oversized vectors with the expectation the backend will legalize it. In order to avoid changing the vectorizer and potentially harm our AVX2 codegen this patch tries to make the legalizer behavior similar.

This is restricted to CPUs that support AVX512F and AVX512VL so that we have good fallback options to use 128 and 256-bit vectors and still get masking.

I've qualified every place I could find in X86ISelLowering.cpp and added tests cases for many of them with 2 different values for the attribute to see the codegen differences.

We still need to do frontend work for the attribute and teach the inliner how to merge it, etc. But this gets the codegen layer ready for it.

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

llvm-svn: 324834

[X86] Remove setOperationAction lines for promoting vXi1 SINT_TO_FP/UINT_TO_FP.

We promote these via a DAG combine now before lowering gets the chance.

Also remove the v2i1 custom handling since it will no longer be triggered.

llvm-svn: 324833

[SelectionDAG] Remove TargetLowering::getConstTrueVal. Use SelectionDAG::getBoolConstant in the one place it was used.

SelectionDAG::getBoolConstant was recently introduced. At the time I didn't know getConstTrueVal existed, but I think getBoolConstant is better as it will use the source VT to make sure it can properly detect floating point if it is configured differently.

llvm-svn: 324832

[X86] Remove some redundant qualifications from the setOperationAction blocks. NFC

These were added as part of the refactoring for prefer vector width. At the time I thought the hasAVX512 here would be replaced with "allow 512 bit vectors" so that it would read "allow 512 bit vectors OR VLX". But now the plan is to only give the option of disabling 512 bit vectors when VLX is enabled. So we don't need this qualification at all

llvm-svn: 324831

Fixed extra ‘;’ warning

llvm-svn: 324830

[X86][SSE] Add SMIN/SMAX combine test

As discussed on D43014, we need the ability to flip SMIN/SMAX to (legal) UMIN/UMAX

llvm-svn: 324829

[X86] Change the signature of the AVX512 packed fp compare intrinsics to return vXi1 mask. Make bitcasts to scalar explicit in IR

Summary: This is the clang equivalent of r324827

Reviewers: zvi, delena, RKSimon, spatel

Reviewed By: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 324828

[X86] Change signatures of avx512 packed fp compare intrinsics to return a vXi1 mask type to be closer to an fcmp.

Summary:
This patch changes the signature of the avx512 packed fp compare intrinsics to return a vXi1 vector and no longer take a mask as input. The casts to scalar type will now need to be explicit in the IR. The masking node will now be an explicit and in the IR.

This makes the intrinsic look much more similar to an fcmp instruction that we wish we could use for these but can't. We already use icmp instructions for integer compares.

Previously the lowering step of isel would turn the intrinsic into an X86 specific ISD node and a emit the masking nodes as well as some bitcasts. This means DAG combines can't see the vXi1 type until somewhat late, making it more difficult to combine out gpr<->mask transition sequences. By exposing the vXi1 type explicitly in the IR and initial SelectionDAG we give earlier DAG combines and even InstCombine the chance to see it and optimize it.

This should make any issues with gpr<->mask sequences the same between integer and fp. Meaning we only have to fix them once.

Reviewers: spatel, delena, RKSimon, zvi

Reviewed By: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 324827

[X86][SSE] Add UMIN/UMAX combine test

As discussed on D43014, we need the ability to flip UMIN/UMAX to (legal) SMIN/SMAX

llvm-svn: 324826

[InstCombine] Add constant vector support for ~(C >> Y) --> ~C >> Y

Includes adding m_NonNegative constant pattern matcher

llvm-svn: 324825

Fix test clang-diff-json.cpp

Summary:
This test would fail if the python path had spaces. Add a quote around the path to fix this problem and update some test values changed by the addition of quotes around the path.

Tested on Windows and Linux with Python 3.x

Reviewers: zturner, llvm-commits

Subscribers: klimek, cfe-commits

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

llvm-svn: 324824

[X86][SSE] Increase PMULLD costs to better match hardware

Until Skylake, most hardware could only issue a PMULLD op every other cycle

llvm-svn: 324823

[X86] Custom legalize (v2i32 (setcc (v2f32))) so that we don't end up with a (v4i1 (setcc (v4f32)))

Undef VLX, getSetCCResultType returns v2i1/v4i1 for v2f32/v4f32 so default type legalization will end up changing the setcc result type back to vXi1 if it had been extended. The resulting extend gets messed up further by type legalization and is difficult to recombine back to (v4i32 (setcc (v4f32))) after legalization.

I went ahead and enabled this for SSE2 and later since its always the result we want and this helps type legalization get there in less steps.

llvm-svn: 324822

Use RelType instead of uint32_t in DynamicReloc. NFC

llvm-svn: 324821

[X86] Extend inputs with elements smaller than i32 to sint_to_fp/uint_to_fp before type legalization.

This prevents extends of masks being introduced during lowering where it become difficult to combine them out.

There are a few oddities in here.

We sometimes concatenate two k-registers produced by two compares, sign_extend the combined pair, then extract two halves. This worked better previously because the sign_extend wasn't created until after the fp_to_sint was split which led to a split sign_extend being created.

We probably also need to custom type legalize (v2i32 (sext v2i1)) via widening.

llvm-svn: 324820

[X86] Remove some check-prefixes from avx512-cvt.ll to prepare for an upcoming patch.

The update script sometimes has trouble when there are check-prefixes representing every possible combination of feature flags. I have a patch where the update script was generating something that didn't pass lit.

This patch just removes some check-prefixes and expands out some of the checks to workaround this.

llvm-svn: 324819

Add vector add/sub/mul/div by scalar tests (PR27085)

Ensure the scalar is correctly splatted to all lanes

llvm-svn: 324818

[x86] preserve test intent by removing undef

D43141 proposes to correct undef folding in the DAG,
and this test would not survive that change.

llvm-svn: 324817

[x86] preserve test intent by removing undef

D43141 proposes to correct undef folding in the DAG,
and this test would not survive that change.

llvm-svn: 324816

Fix Wdocumentation warning. NFCI.

llvm-svn: 324815

[ARM] preserve test intent by removing undef

D43141 proposes to correct undef folding in the DAG,
and this test would not survive that change.

llvm-svn: 324814

Fix Wdocumentation warnings. NFCI.

llvm-svn: 324813

[X86][SSE] Regenerate old sitofp v2i32 test

llvm-svn: 324812

Correct a typo in tsan_pthread_setname_np in the FreeBSD code

Noted by David CARLIER.

llvm-svn: 324811

Mark the textdomain.cc test as unsupported on BSDs

textdomain is a part of -lintl on BSDs. In GLIBC it's in libc.

We assume that -lintl will need to be rebuilt with sanitizers
in order to sanitize programs using its features.

This is a proper continuation of D41013.

The original patch has been reverted (adding -lintl).

llvm-svn: 324810

Make a build bot happy.

llvm-svn: 324809

[Templight] Template Instantiation Observer

This patch adds a base-class called TemplateInstantiationObserver which gets
notified whenever a template instantiation is entered or exited during
semantic analysis. This is a base class used to implement the template
profiling and debugging tool called
Templight (https://github.com/mikael-s-persson/templight).

The patch also makes a few more changes:

* ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h).
* CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function).
* TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers.
* Notifications to the template-inst observer are added at the key places where templates are instantiated.

Patch by: Abel Sinkovics!

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

llvm-svn: 324808

[XRay] Rename Buffer.Buffer to Buffer.Data

Summary: some compiler (msvc) treats Buffer.Buffer as constructor and refuse to compile. NFC

Authored by comicfans44.

Reviewers: rnk, dberris

Reviewed By: dberris

Subscribers: llvm-commits

Tags: #sanitizers

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

llvm-svn: 324807

[X86] Custom legalize (v2i1 (fp_to_uint/fp_to_sint v2f64)) without AVX512VL.

Strangely the code was already present, just the setOperationAction wasn't being called without VLX.

llvm-svn: 324806

[X86] Legalize zero extends from vXi1 to vXi16/vXi32/vXi64 using a sign extend and a shift.

This avoids a constant pool load to create 1.

The int->float are showing converts to mask and back. We probably need to widen inputs to sint_to_fp/uint_to_fp before type legalization.

llvm-svn: 324805

[X86] Teach combineExtSetcc to handle ZERO_EXTEND by widening the setcc and then masking. A later DAG combine will convert to a shift.

This helps to avoid a constant pool load needed to zero extend from the mask.

llvm-svn: 324804

[utils] Refactor utils/update_{,llc_}test_checks.py to share more code

Summary:
This revision refactors 1. parser 2. CHECK line adder of utils/update_{,llc_}test_checks.py
so that thir functionality can be re-used by other utility scripts (e.g.  D42712)

Reviewers: asb, craig.topper, RKSimon, echristo

Subscribers: llvm-commits, spatel

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

llvm-svn: 324803

[analyzer] NFC: Assert that our fix for noreturn destructors keeps working.

Massive false positives were known to be caused by continuing the analysis
after a destructor with a noreturn attribute has been executed in the program
but not modeled in the analyzer due to being missing in the CFG.

Now that work is being done on enabling the modeling of temporary constructors
and destructors in the CFG, we need to make sure that the heuristic that
suppresses these false positives keeps working when such modeling is disabled.
In particular, different code paths open up when the corresponding constructor
is being inlined during analysis.

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

llvm-svn: 324802

[analyzer] Fix a merge error in -analyzer-config tests.

It was introduced when two -analyzer-config options were added almost
simultaneously in r324793 and r324668 and the option count was not
rebased correctly in the tests.

Fixes the buildbots.

llvm-svn: 324801

[analyzer] NFC: Use CFG construction contexts instead of homemade lookahead.

The analyzer was relying on peeking the next CFG element during analysis
whenever it was trying to figure out what object is being constructed
by a given constructor. This information is now available in the current CFG
element in all cases that were previously supported by the analyzer,
so no complicated lookahead is necessary anymore.

No functional change intended - the context in the CFG should for now be
available if and only if it was previously discoverable via CFG lookahead.

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

llvm-svn: 324800

Use multi-key tree search for {map, set}::{count, equal_range}

Patch from ngolovliov@gmail.com
Reviewed as: https://reviews.llvm.org/D42344

As described in llvm.org/PR30959, the current
implementation of std::{map, key}::{count, equal_range} in libcxx is
non-conforming. Quoting the C++14 standard [associative.reqmts]p3

> The phrase “equivalence of keys” means the equivalence relation imposed by
> the comparison and not the operator== on keys. That is, two keys k1 and k2 are
> considered to be equivalent if for the comparison object comp,
> comp(k1, k2) == false && comp(k2, k1) == false.

In the same section, the requirements table states the following:

> a.equal_range(k) equivalent to make_pair(a.lower_bound(k), a.upper_bound(k))
> a.count(k) returns the number of elements with key equivalent to k

The behaviour of libstdc++ seems to conform to the standard here.

llvm-svn: 324799

[CFG] Provide construction contexts when constructors have cleanups.

Now that we make it possible to query the CFG constructor element to find
information about the construction site, possible cleanup work represented by
ExprWithCleanups should not prevent us from providing this information.

This allows us to have a correct construction context for variables initialized
"by value" via elidable copy-constructors, such as 'i' in

  iterator i = vector.begin();

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

llvm-svn: 324798

[DAG] Make early exit hasPredecessorHelper return true. NFCI.

All uses conservatively assume in early exit case that it will be a
predecessor. Changing default removes checking code in all uses.

llvm-svn: 324797

[CFG] Add construction context for constructor initializers.

CFG elements for constructors of fields and base classes that are being
initialized before the body of the whole-class constructor starts can now be
queried to discover that they're indeed participating in initialization of their
respective fields or bases before the whole-class constructor kicks in.

CFG construction contexts are now capable of representing CXXCtorInitializer
triggers, which aren't considered to be statements in the Clang AST.

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

llvm-svn: 324796

Looks like this fails when built i386 on linux bots, possible target
arch incompat with spec in file so it's rejected and the test fails.
will look into this later, will be a test case issue not a test issue;
test case may only be valid when lldb is built for/running on an x86_64
system.

llvm-svn: 324795

[CFG] Add construction context for simple variable declarations.

Constructors of simple variables now can be queried to discover that they're
constructing into simple variables.

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

llvm-svn: 324794

[analyzer] Serialize statistics to plist when serialize-stats=true is set

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

llvm-svn: 324793

Add test case for x86_64 architecture recognition in the
target.xml packet if it is included.

llvm-svn: 324792

[X86] Teach combineInsertSubvector how to combine some k-register insert_subvectors and extract_subvector sequences to remove extra zeroing.wq

llvm-svn: 324791

[analyzer] Add missing pre-post-statement callbacks for OffsetOfExpr.

This expression may or may not be evaluated in compile time, so tracking the
result symbol is of potential interest. However, run-time offsetof is not yet
supported by the analyzer, so for now this callback is only there to assist
future implementation.

Patch by Henry Wong!

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

llvm-svn: 324790

[analyzer] Add support for __builtin_constant_p.

This builtin is evaluated in compile time. But in the analyzer we don't yet
automagically evaluate all calls that can be evaluated in compile time.

Patch by Felix Kostenzer!

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

llvm-svn: 324789

Make LLVM timer reprintable: that is, make more than one print action on the same timer feasible

Currently, each LLVM timer can be only printed once, as the act of
printing clears the timer.

Moreover, the current printing mechanism implicitly assumes that the
timer is stopped -- and prints zero otherwise.
This patch relaxes this assumption and makes printing statistics
multiple time a possibility.

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

llvm-svn: 324788

REQUIRES: shell a couple of tests that require the shell

One test uses diff, the other tries to change the PATH which doesn't
seem to work well ('not' is no longer accessible/found after the PATH is
changed - I think $PATH isn't expanded when setting PATH).

llvm-svn: 324787

[LV] Fix analyzeInterleaving when -pass-remarks enabled

Summary:
If -pass-remarks=loop-vectorize, atomic ops will be seen by
analyzeInterleaving(), even though canVectorizeMemory() == false. This
is because we are requesting extra analysis instead of bailing out.

In such a case, we end up with a Group in both Load- and StoreGroups,
and then we'll try to access freed memory when traversing LoadGroups after having had released the Group when  iterating over StoreGroups.

The fix is to include mayWriteToMemory() when validating that two
instructions are the same kind of memory operation.

Reviewers: mssimpso, davidxl

Reviewed By: davidxl

Subscribers: hsaito, fhahn, llvm-commits

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

llvm-svn: 324786

[analyzer] Introduce statistics for the total number of visited basic blocks

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

llvm-svn: 324785

[Hexagon] Update uses of deprecated IRBuilder CreateMemCpy/Move calls

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
Hexagon LoopIdiom pass to cease using the old IRBuilder createMemCpy/createMemMove
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, rL324642, rL324653, rL324654, rL324773, rL324774,
rL324781 )
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: 324784

[llvm-objcopy] Make modifications in-place if output is not specified

If the output file is not specified make the modifications in-place
(like binutils objcopy does). In particular, this fixes
the behavior of Clang -gsplit-dwarf (if Clang is configured to use llvm-objcopy),
previously it was creating .dwo files, but still leaving *dwo* sections in
the original binary.

Test plan: make check-all

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

llvm-svn: 324783

[X86] Teach lower1BitVectorShuffle to recognize shuffles that are just filling upper elements with zero. Replace with insert_subvector.

There's still some extra kshifts in one of the modified test cases here, but hopefully that's only a DAG combine away.

llvm-svn: 324782

[ARMFastISel] Replace deprecated calls to MemoryIntrinsic::getAlignment() (NFCI)

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
ARMFastISel to cease using the old getAlignment() 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, rL324654, rL324773, rL324774 )
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: 324781

[NFC] Extract method to SourceManager for traversing the macro "stack"

The code for going up the macro arg expansion is duplicated in many
places (and we need it for the analyzer as well, so I did not want to
duplicate it two more times).

This patch is an NFC, so the semantics should remain the same.

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

llvm-svn: 324780

CMake: Allow specifying arbitrary CCACHE parameters

Introduces the LLVM_CCACHE_PARAMS cmake variable, which can be used to
pass arbitrary parameters to ccache invocations.

llvm-svn: 324779

[WebAssembly] Add mechanisms for specifying an explicit import module name.

This adds a wasm-import-module function attribute and a .import_module
assembler directive, for specifying module import names for WebAssembly.
Currently these may only be used for function symbols; global variables
may be considered in the future.

WebAssembly has a two-level namespace scheme for symbols, and it's
normally the linker's job to assign the module name, which is the
first-level name. The attributes here allow users to specify their
own module names explicitly, which is useful for tools generating
bindings to modules defined in other languages.

This feature is not fully usable yet. It will evolve along with the
ongoing symbol table and lld changes.

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

llvm-svn: 324778

[WebAssembly] Add an LLVM_FALLTHROUGH to address a warning. NFC.

llvm-svn: 324777

[CodeGen] Use the zero initializer instead of storing an all zero representation.

Summary:
This change avoids the overhead of storing, and later crawling,
an initializer list of all zeros for arrays. When LLVM
visits this (llvm/IR/Constants.cpp) ConstantArray::getImpl()
it will scan the list looking for an array of all zero.

We can avoid the store, and short-cut the scan, by detecting
all zeros when clang builds-up the initialization representation.

This was brought to my attention when investigating PR36030

Reviewers: majnemer, rjmccall

Reviewed By: rjmccall

Subscribers: cfe-commits

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

llvm-svn: 324776

Make LLDB's clang module cache path customizable

This patch makes LLDB's clang module cache path customizable via
settings set target.clang-modules-cache-path <path> and uses it in the
LLDB testsuite to reuse the same location inside the build directory
for LLDB and clang.

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

llvm-svn: 324775

[AMDGPUPromoteAlloca] Replace deprecated memory intrinsic APIs (NFCI)

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
AMDGPUPromoteAlloca pass to cease using:
1) The old getAlignment() API of MemoryIntrinsic in favour of getting source & dest specific
alignments through the new API.
2) The old IRBuilder createMemCpy/createMemMove 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, r323891, rL324148, rL324273, rL324278,
rL324384, rL324395, rL324402, rL324626, rL324642, rL324653, rL324654, rL324773 )
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: 324774

[AArch64FastISel] Replace deprecated calls to MemoryIntrinsic::getAlignment() (NFCI)

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
AArch64FastISel to cease using the old getAlignment() 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, r323891, rL324148, rL324273, rL324278,
rL324384, rL324395, rL324402, rL324626, rL324642, rL324653, rL324654 )
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: 324773