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
[SystemZ] Make use of SUBTRACT HALFWORD

Thanks to Ulrich Weigand for noticing that this instruction was missing.


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

[PowerPC] Remove need for adjustFixupOffst hack

Now that applyFixup understands differently-sized fixups, we can define
fixup_ppc_lo16/fixup_ppc_lo16_ds/fixup_ppc_ha16 to properly be 2-byte
fixups, applied at an offset of 2 relative to the start of the 
instruction text.

This has the benefit that if we actually need to generate a real
relocation record, its address will come out correctly automatically,
without having to fiddle with the offset in adjustFixupOffset.

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@181894 91177308-0d34-0410-b5e6-96231b3b80d8

Remove MCELFObjectTargetWriter::adjustFixupOffset hack

Now that PowerPC no longer uses adjustFixupOffset, and no other
back-end (ever?) did, we can remove the infrastructure itself
(incidentally addressing a FIXME to that effect).



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181895 91177308-0d34-0410-b5e6-96231b3b80d8
Support unaligned load/store on more ARM targets

This patch matches GCC behavior: the code used to only allow unaligned
load/store on ARM for v6+ Darwin, it will now allow unaligned load/store for
v6+ Darwin as well as for v7+ on other targets.

The distinction is made because v6 doesn't guarantee support (but LLVM assumes
that Apple controls hardware+kernel and therefore have conformant v6 CPUs),
whereas v7 does provide this guarantee (and Linux behaves sanely).

Overall this should slightly improve performance in most cases because of
reduced I$ pressure.

Patch by JF Bastien

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