Test commit.

The keyword "virtual" is not necessary.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209501 91177308-0d34-0410-b5e6-96231b3b80d8
Typedef NumeredTypesMapTy is not used anywhere.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209502 91177308-0d34-0410-b5e6-96231b3b80d8
[YAML] Add an optional argument `EnumMask` to the `yaml::IO::bitSetCase()`.

Some bit-set fields used in ELF file headers in fact contain two parts.
The first one is a regular bit-field. The second one is an enumeraion.
For example ELF header `e_flags` for MIPS target might contain the
following values:

Bit-set values:

  EF_MIPS_NOREORDER = 0x00000001
  EF_MIPS_PIC       = 0x00000002
  EF_MIPS_CPIC      = 0x00000004
  EF_MIPS_ABI2      = 0x00000020

Enumeration:

  EF_MIPS_ARCH_32   = 0x50000000
  EF_MIPS_ARCH_64   = 0x60000000
  EF_MIPS_ARCH_32R2 = 0x70000000
  EF_MIPS_ARCH_64R2 = 0x80000000

For printing bit-sets we use the `yaml::IO::bitSetCase()`. It does not
support bit-set/enumeration combinations and prints too many flags from
an enumeration part. This patch fixes this problem. New method
`yaml::IO::maskedBitSetCase()` handle "enumeration" part of bitset
defined by provided mask.

Patch reviewed by Nick Kledzik and Sean Silva.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209504 91177308-0d34-0410-b5e6-96231b3b80d8
Fixup sys::getHostCPUFeatures crypto names so it doesn't clash with kernel headers

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209506 91177308-0d34-0410-b5e6-96231b3b80d8
Updated the llvm.mem.parallel_loop_access semantics to include the possibility
to have only some of the loop's memory instructions be annotated and still _help_
the loop carried dependence analysis. 

This was discussed in the llvmdev ML (topic: "parallel loop metadata question").


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209507 91177308-0d34-0410-b5e6-96231b3b80d8
[asan] properly instrument memory accesses that have small alignment (smaller than min(8,size)) by making two checks instead of one. This may slowdown some cases, e.g. long long on 32-bit or wide loads produced after loop unrolling. The benefit is higher sencitivity.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209508 91177308-0d34-0410-b5e6-96231b3b80d8
[mips][mips64r6] [ls][dw][lr] are not available in MIPS32r6/MIPS64r6

Summary:
Instead the system is required to provide some means of handling unaligned
load/store without special instructions. Options include full hardware
support, full trap-and-emulate, and hybrids such as hardware support within
a cache line and trap-and-emulate for multi-line accesses.

MipsSETargetLowering::allowsUnalignedMemoryAccesses() has been configured to
assume that unaligned accesses are 'fast' on the basis that I expect few
hardware implementations will opt for pure-software handling of unaligned
accesses. The ones that do handle it purely in software can override this.

mips64-load-store-left-right.ll has been merged into load-store-left-right.ll

The stricter testing revealed a Bits!=Bytes bug in passByValArg(). This has
been fixed and the variables renamed to clarify the units they hold.

Reviewers: zoran.jovanovic, jkolek, vmedic

Reviewed By: vmedic

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209512 91177308-0d34-0410-b5e6-96231b3b80d8
[mips][mips64r6] t(eq|ge|lt|ne)i and t(ge|lt)iu are not available in MIPS32r6/MIPS64r6

Summary: Depends on D3872

Reviewers: jkolek, zoran.jovanovic, vmedic

Reviewed By: vmedic

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209513 91177308-0d34-0410-b5e6-96231b3b80d8
[mips] Work around inconsistency in llvm-mc's placement of fixup markers

Summary:
Add a second fixup table to MipsAsmBackend::getFixupKindInfo() to correctly
position llvm-mc's fixup placeholders for big-endian.

See PR19836 for full details of the issue. To summarize, the fixup placeholders
do not account for endianness properly and the implementations of
getFixupKindInfo() for each target are measuring MCFixupKindInfo.TargetOffset
from different ends of the instruction encoding to compensate.

Reviewers: jkolek, zoran.jovanovic, vmedic

Reviewed By: vmedic

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

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

GV is never used past this point. This was probably a copy and paste error.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209518 91177308-0d34-0410-b5e6-96231b3b80d8
Aliases are always definition, delete dead code.

While at it, use a range loop.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209519 91177308-0d34-0410-b5e6-96231b3b80d8
Teach the table generated emitPseudoExpansionLowering function to not emit a switch statement containing only a default statement (and no cases). Updated some of the code to use range-based for loops as well. No functional changes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209521 91177308-0d34-0410-b5e6-96231b3b80d8
Convert test to use FileCheck.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209528 91177308-0d34-0410-b5e6-96231b3b80d8
Add FIXME comment based on code review feedback by Hal Finkel on r209338

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209529 91177308-0d34-0410-b5e6-96231b3b80d8
[RuntimeDyld] Remove relocation bounds check introduced in r208375 (MachO only).

We do all of our address arithmetic in 64-bit, and operations involving
logically negative 32-bit offsets (actually represented as unsigned 64 bit ints)
often overflow into higher bits. The overflow check could be preserved by
casting to uint32 at the callsite for applyRelocationValue, but this would
eliminate the value of the check.

The right way to handle overflow in relocations is to make relocation processing
target specific, and compute the values for RelocationEntry objects in the
appropriate types (32-bit for 32-bit targets, 64-bit for 64-bit targets). This
is coming as part of the cleanup I'm working on.

This fixes another i386 regression test.

<rdar://problem/16889891>



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209536 91177308-0d34-0410-b5e6-96231b3b80d8
Add the extracted constant offset using GEP

Fixed a TODO in r207783.

Add the extracted constant offset using GEP instead of ugly
ptrtoint+add+inttoptr. Using GEP simplifies future optimizations and makes IR
easier to understand. 

Updated all affected tests, and added a new test in split-gep.ll to cover a
corner case where emitting uglygep is necessary.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209537 91177308-0d34-0410-b5e6-96231b3b80d8
Fix broken FileCheck prefixes

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209538 91177308-0d34-0410-b5e6-96231b3b80d8
Remove unused CHECK lines

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209539 91177308-0d34-0410-b5e6-96231b3b80d8
Use alias linkage and visibility to decide tls access mode.

This matches both what we do for the non-thread case and what gcc does.

With this patch clang would match gcc's behaviour in

static __thread int a = 42;
extern __thread int b __attribute__((alias("a")));
int *f(void) { return &a; }
int *g(void) { return &b; }

if not for pr19843. Manually writing the IL does produce the same access modes.

It is also a step in the direction of fixing pr19844.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209543 91177308-0d34-0410-b5e6-96231b3b80d8
Revert part of "Fix broken FileCheck prefixes"

This reverts part of commit r209538.

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