Make getCompileUnit non-const and return the current DIE if it
happens to be a compile unit. Noticed on inspection and tested
via calling on a newly created compile unit. No functional change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181835 91177308-0d34-0410-b5e6-96231b3b80d8
Add -Wreorder to the list of C++ warnings.

This built clean with clang, but if we see false positives on the bots
then we'll revert and turn it into a compiler specific check.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181836 91177308-0d34-0410-b5e6-96231b3b80d8
Revert previous patch, it's actually on under Wall.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181837 91177308-0d34-0410-b5e6-96231b3b80d8
GlobalOpt: fix an issue where CXAAtExitFn points to a deleted function.

CXAAtExitFn was set outside a loop and before optimizations where functions
can be deleted. This patch will set CXAAtExitFn inside the loop and after
optimizations.

Seg fault when running LTO because of accesses to a deleted function.
rdar://problem/13838828


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181838 91177308-0d34-0410-b5e6-96231b3b80d8
ARM ISel: Don't create illegal types during LowerMUL

The transformation happening here is that we want to turn a
"mul(ext(X), ext(X))" into a "vmull(X, X)", stripping off the extension. We have
to make sure that X still has a valid vector type - possibly recreate an
extension to a smaller type. In case of a extload of a memory type smaller than
64 bit we used create a ext(load()). The problem with doing this - instead of
recreating an extload - is that an illegal type is exposed.

This patch fixes this by creating extloads instead of ext(load()) sequences.

Fixes PR15970.

radar://13871383

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181842 91177308-0d34-0410-b5e6-96231b3b80d8
Object: Fix Mach-O relocation printing.

There were two problems that made llvm-objdump -r crash:
- for non-scattered relocations, the symbol/section index is actually in the
  (aptly named) symbolnum field.
- sections are 1-indexed.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181843 91177308-0d34-0410-b5e6-96231b3b80d8
ExceptionDemo: Corresponding to r181820, SectionMemoryManager should belong to RTDyldMemoryManager.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181848 91177308-0d34-0410-b5e6-96231b3b80d8
Speed up Value::isUsedInBasicBlock() for long use lists.

This is expanding Ben's original heuristic for short basic blocks to
also work for longer basic blocks and huge use lists.

Scan the basic block and the use list in parallel, terminating the
search when the shorter list ends. In almost all cases, either the basic
block or the use list is short, and the function returns quickly.

In one crazy test case with very long use chains, CodeGenPrepare runs
400x faster. When compiling ARMDisassembler.cpp it is 5x faster.

<rdar://problem/13840497>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181851 91177308-0d34-0410-b5e6-96231b3b80d8
LoopVectorize: Hoist conditional loads if possible

InstCombine can be uncooperative to vectorization and sink loads into
conditional blocks. This prevents vectorization.

Undo this optimization if there are unconditional memory accesses to the same
addresses in the loop.

radar://13815763

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

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181862 91177308-0d34-0410-b5e6-96231b3b80d8
ELFRelocationEntry::operator<(): Try to stabilize the order. r_offset was insufficient to sort Relocs.

It should fix llvm/test/CodeGen/ARM/ehabi-mc-compact-pr*.ll on some hosts.

  RELOCATION RECORDS FOR [.ARM.exidx]:
  0 R_ARM_PREL31 .text
  0 R_ARM_NONE __aeabi_unwind_cpp_pr0

FIXME: I am not sure of the directions of extra comparators, in Type and Index.
For now, they are different from the direction in r_offset.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181864 91177308-0d34-0410-b5e6-96231b3b80d8
Use only explicit bool conversion operators

BitVector/SmallBitVector::reference::operator bool remain implicit since
they model more exactly a bool, rather than something else that can be
boolean tested.

The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.

One behavior change (YAMLParser) was made, though no test case is
included as I'm not sure how to reach that code path. Essentially any
comparison of llvm::yaml::document_iterators would be invalid if neither
iterator was at the end.

This helped uncover a couple of bugs in Clang - test cases provided for
those in a separate commit along with similar changes to `operator bool`
instances in Clang.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181873 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Consolidate assembler tests into 4 big tests


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181878 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Consolidate disassembler tests for valid input into 2 big tests


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181879 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Add more future work items to the README

Based on an analysis by Ulrich Weigand.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181882 91177308-0d34-0410-b5e6-96231b3b80d8
Add Jade to the list of external projects using LLVM in the release notes.

Patch by: Antoine Lorence <Antoine.Lorence@insa-rennes.fr>

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

[PowerPC] Correctly handle fixups of other than 4 byte size

The PPCAsmBackend::applyFixup routine handles the case where a
fixup can be resolved within the same object file.  However,
this routine is currently hard-coded to assume the size of
any fixup is always exactly 4 bytes.

This is sort-of correct for fixups on instruction text; even
though it only works because several of what really would be
2-byte fixups are presented as 4-byte fixups instead (requiring
another hack in PPCELFObjectWriter::adjustFixupOffset to clean
it up).

However, this assumption breaks down completely for fixups
on data, which legitimately can be of any size (1, 2, 4, or 8).

This patch makes applyFixup aware of fixups of varying sizes,
introducing a new helper routine getFixupKindNumBytes (along
the lines of what the ARM back end does).  Note that in order
to handle fixups of size 8, we also need to fix the return type
of adjustFixupValue to uint64_t to avoid truncation.

Tested on both 64-bit and 32-bit PowerPC, using external and
integrated assembler.



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

[PowerPC] Add test case for r181891



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