Don't manually (and forcibly) run the verifier on the entire module from
the jump instruction table pass. First, the verifier is already built
into all the tools. The test case is adapted to just run llvm-as
demonstrating that we still catch the broken module. Second, the
verifier is *extremely* slow. This was responsible for very significant
compile time regressions.

If you have deployed a Clang binary anywhere from r210280 to this
commit, you really want to re-deploy.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214287 91177308-0d34-0410-b5e6-96231b3b80d8
SPRG 0 to 3 are valid outside BookE, so move them to the normal test
file. Add support for accessing SPRG 4 to 7 on BookE.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214295 91177308-0d34-0410-b5e6-96231b3b80d8
Add BookE's wrtee and wrteei instructions.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214297 91177308-0d34-0410-b5e6-96231b3b80d8
Correct vector type definition in LangRef.

According to VectorType::isValidElementType, any integer, floating point
or pointer type is a valid vector element type.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214302 91177308-0d34-0410-b5e6-96231b3b80d8
Add a small test showing when a linkonce_odr symbol can be hidden.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214311 91177308-0d34-0410-b5e6-96231b3b80d8
Add the missing hasLinkOnceODRLinkage predicate.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214312 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-uselistorder: Fix memory leak from r214125

Turns out `parseBitcodeFile()` does *not* take ownership of the buffer.
This was already clear in the header docs, but I obviously didn't read
them (having noticed that it gets stored in a `unique_ptr<>`).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214313 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-uselistorder: Improve the tool description

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214317 91177308-0d34-0410-b5e6-96231b3b80d8
Rename llvm-uselistorder => verify-uselistorder

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214318 91177308-0d34-0410-b5e6-96231b3b80d8
Fix line endings before adding RUN lines, NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214320 91177308-0d34-0410-b5e6-96231b3b80d8
UseListOrder: Visit global values

When predicting use-list order, we visit functions in reverse order
followed by `GlobalValue`s and write out use-lists at the first
opportunity.  In the reader, this will translate to *after* the last use
has been added.

For this to work, we actually need to descend into `GlobalValue`s.
Added a targeted test in `use-list-order.ll` and `RUN` lines to the
newly passing tests in `test/Bitcode`.

There are two remaining failures in `test/Bitcode`:

  - blockaddress.ll: I haven't thought through how to model the way
    block addresses change the order of use-lists (or how to work around
    it).

  - metadata-2.ll: There's an old-style `@llvm.used` global array here
    that I suspect the .ll parser isn't upgrading properly.  When it
    round-trips through bitcode, the .bc reader *does* upgrade it, so
    the extra variable (`i8* null`) has an extra use, and the shuffle
    vector doesn't match.

    I think the fix is to upgrade old-style global arrays (or reject
    them?) in the .ll parser.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214321 91177308-0d34-0410-b5e6-96231b3b80d8
Retain alignment requirements for load->selects modified by DAGCombine

DAGCombine may choose to rewrite graphs where two loads feed a select into
graphs where a select of two addresses feed a load. While it sanity checks the
loads to make sure they are broadly equivalent it currently just uses the
alignment restriction of the left node. In cases where the right node has
stronger alignment requiresment this may lead to bad codegen, such as generating
an aligned load where an unaligned load is required. This patch makes the
combine generate a load with an alignment that is the same as whichever is more
restrictive of the two alignments.

Tests included.

rdar://17762530

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214322 91177308-0d34-0410-b5e6-96231b3b80d8
Fixing a few -Woverloaded-virtual warnings by exposing the hidden virtual function as well. No functional changes intended.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214328 91177308-0d34-0410-b5e6-96231b3b80d8
LangRef: add a note about the mangling-suppressing \01 prefix

Someone asked about this on IRC the other day, and I couldn't
find the magic prefix documented anywhere.

Differential Revision: http://reviews.llvm.org/D4728

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214329 91177308-0d34-0410-b5e6-96231b3b80d8
Fix test case introduced in r214322

This patch adds an explicit triple to the test case introduced by r214322. This
should fix build failueres that are occuring on bots that are cross building.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214330 91177308-0d34-0410-b5e6-96231b3b80d8
docs: update the command guide documentation for llvm-profdata.

Differential Revision: http://reviews.llvm.org/D4726


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214331 91177308-0d34-0410-b5e6-96231b3b80d8
Add BookE's tlbre, tlbwe and tlbivax instructions.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214332 91177308-0d34-0410-b5e6-96231b3b80d8
SimplifyCFG: Avoid miscompilations due to removed lifetime intrinsics.

The lifetime intrinsics need some work in order to make it clear which
optimizations are or are not valid.

For now dropping this optimization avoids a miscompilation.

Patch by Björn Steinbrink.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214336 91177308-0d34-0410-b5e6-96231b3b80d8
SLP Vectorizer: Canonicalize tree operands of commutitive binary operands.

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