[msan] Fix bad interaction between with-calls mode and chained origin tracking.

Origin history should only be recorded for uninitialized values, because it is
meaningless otherwise. This change moves __msan_chain_origin to the runtime
library side and makes it conditional on the corresponding shadow value.

Previous code was correct, but _very_ inefficient.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211700 91177308-0d34-0410-b5e6-96231b3b80d8
Simplify AddValueSymbols. No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211701 91177308-0d34-0410-b5e6-96231b3b80d8
Random Number Generator (llvm)

Provides an abstraction for a random number generator (RNG) that produces a stream of pseudo-random numbers.
The current implementation uses C++11 facilities and is therefore not cryptographically secure.

The RNG is salted with the text of the current command line invocation.
In addition, a user may specify a seed (reproducible builds).

In clang, the seed can be set via

-frandom-seed=X
In the back end, the seed can be set via

-rng-seed=X
This is the llvm part of the patch.
clang part: D3391

URL: http://reviews.llvm.org/D3390
Author: yln

I'm landing this for the second time, it broke Windows bots the first time around.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211705 91177308-0d34-0410-b5e6-96231b3b80d8
Simplify the visitation of target expressions. No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211707 91177308-0d34-0410-b5e6-96231b3b80d8
Fix = delete in MSVC build from r211705

MSVC doesn't support = delete yet, use LLVM_DELETED_FUNCTION instead.

Related to: http://reviews.llvm.org/D3390

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211709 91177308-0d34-0410-b5e6-96231b3b80d8
Rename loop unrolling and loop vectorizer metadata to have a common prefix.

[LLVM part]

These patches rename the loop unrolling and loop vectorizer metadata
such that they have a common 'llvm.loop.' prefix.  Metadata name
changes:

llvm.vectorizer.* => llvm.loop.vectorizer.*
llvm.loopunroll.* => llvm.loop.unroll.*

This was a suggestion from an earlier review
(http://reviews.llvm.org/D4090) which added the loop unrolling
metadata. 

Patch by Mark Heffernan.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211710 91177308-0d34-0410-b5e6-96231b3b80d8
Add some test files for r211710.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211711 91177308-0d34-0410-b5e6-96231b3b80d8
Move expression visitation logic up to MCStreamer.

Remove the duplicate from MCRecordStreamer. No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211714 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the build.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211715 91177308-0d34-0410-b5e6-96231b3b80d8
Fix indentation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211717 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Always prefer to lower a VECTOR_SHUFFLE into a BLENDI instead of SHUFP (or VPERM2X128).

This patch teaches method 'LowerVECTOR_SHUFFLE' to give higher precedence to
the check for 'isBlendMask'; the idea is that, when possible, we should firstly
check if a shuffle performs a blend, and in case, try to lower it into a BLENDI
instead of selecting a SHUFP or (worse) a VPERM2X128.

In general:
 - AVX VBLENDPS/D always have better latency and throughput than VPERM2F128;
 - BLENDPS/D instructions tend to always have better 'reciprocal throughput'
   than the equivalent SHUFPS/D;
 - Both BLENDPS/D and SHUFPS/D are often decoded into the same number of
   m-ops; however, a m-op obtained from a BLENDPS/D can be scheduled to more
   than one execution port.

This patch:
 - Moves the check for 'isBlendMask' immediately before the check for
   'isSHUFPMask' within method 'LowerVECTOR_SHUFFLE';
 - Updates existing tests for sse/avx shuffle/blend instructions to verify
   that we select (v)blendps/d when possible (instead of (v)shufps/d or
   vperm2f128).



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211720 91177308-0d34-0410-b5e6-96231b3b80d8
Add Rpass-missed and Rpass-analysis reports to the loop vectorizer. The remarks give the vector width of vectorized loops and a brief analysis of loops that fail to be vectorized. For example, an analysis will be generated for loops containing control flow that cannot be simplified to a select. The optimization remarks also give the debug location of expressions that cannot be vectorized, for example the location of an unvectorizable call.

Reviewed by: Arnold Schwaighofer


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211721 91177308-0d34-0410-b5e6-96231b3b80d8
PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location.

This situation does bad things when inlined, so I've fixed Clang not to
produce inlinable call sites without locations when the caller has debug
info (in the one case where I could find that this occurred). This
updates the PR20038 test case to be what clang now produces, and readds
the assertion that had to be removed due to this bug.

I've also beefed up the debug info verifier to help diagnose these
issues in the future, and I hope to add checks to the inliner to just
assert-fail if it encounters this situation. If, in the future, we
decide we have to cope with this situation, the right thing to do is
probably to just remove all the DebugLocs from the inlined instructions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211723 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location."

This reverts commit r211723.

Breaks the ASan/compiler-rt build... guess I didn't test very far at all
:/.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211724 91177308-0d34-0410-b5e6-96231b3b80d8
Merge the used symbol scanning of MCObjectStreamer and RecordStreamer.

This completes the refactoring of RecordStreamer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211727 91177308-0d34-0410-b5e6-96231b3b80d8
[FastISel][X86] Only fold the cmp into the select when both instructions are in the same basic block.

If the cmp is in a different basic block, then it is possible that not all
operands of that compare have defined registers. This can happen when one of
the operands to the cmp is a load and the load gets folded into the cmp. In
this case FastISel will skip the load instruction and the vreg is never
defined.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211730 91177308-0d34-0410-b5e6-96231b3b80d8
Mention that Phabricator users should subscribe to *-commits

This probably explains why a lot of messages get lost for first time
Phabricator users.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211731 91177308-0d34-0410-b5e6-96231b3b80d8
[FastISel][X86] Refactor XALU folding. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211735 91177308-0d34-0410-b5e6-96231b3b80d8
The includes were sorted. Revert r210578.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211737 91177308-0d34-0410-b5e6-96231b3b80d8
[FastISel][X86] More refactoring of select lowering and XALU folding. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211740 91177308-0d34-0410-b5e6-96231b3b80d8