Another part of the ARM64 backend (so tests will be following soon).
This is currently used by the linker to relax adrp/ldr pairs into nops
where possible, though could well be more broadly applicable.

llvm-svn: 205084

This was accidentally omitted from r205081.

llvm-svn: 205083

llvm-svn: 205082

The upcoming ARM64 backend doesn't have section-relative relocations,
so we give each section its own symbol to provide this functionality.
Of course, it doesn't need to appear in the final executable, so
linker-private is the best kind for this purpose.

llvm-svn: 205081

ARM64 for iOS is going to want to emit these symbols in a
linker-private style for efficiency, but other targets probably don't
want that behaviour.

llvm-svn: 205080

This is like the LLVMMatchType, except the verifier checks that the
second argument is a vector with the same base type and half the
number of elements.

This will be used by the ARM64 backend.

llvm-svn: 205079

llvm-svn: 205078

On these tests llvm-mc will convert got relocations with a symbol to section
relocations. This is invalid, since the relocation doesn't reference the symbol
itself, so its offset in a section in irrelevant.

Given the object files, these are still valid lld tests, so just run the
tests directly on the binaries.

Found by running check-lld after fixing the relocation handling in llvm-mc.

llvm-svn: 205077

I started trying to fix a small issue, but this code has seen a small fix too
many.

The old code was fairly convoluted. Some of the issues it had:

* It failed to check if a symbol difference was in the some section when
  converting a relocation to pcrel.
* It failed to check if the relocation was already pcrel.
* The pcrel value computation was wrong in some cases (relocation-pc.s)
* It was missing quiet a few cases where it should not convert symbol
  relocations to section relocations, leaving the backends to patch it up.
* It would not propagate the fact that it had changed a relocation to pcrel,
  requiring a quiet nasty work around in ARM.
* It was missing comments.

llvm-svn: 205076

We had stored both f64 values and v2f64, etc. values in the VSX registers. This
worked, but was suboptimal because we would always spill 16-byte values even
through we almost always had scalar 8-byte values. This resulted in an
increase in stack-size use, extra memory bandwidth, etc. To fix this, I've
added 64-bit subregisters of the Altivec registers, and combined those with the
existing scalar floating-point registers to form a class of VSX scalar
floating-point registers. The ABI code has also been enhanced to use this
register class and some other necessary improvements have been made.

llvm-svn: 205075

llvm-svn: 205074

llvm-svn: 205073

llvm-svn: 205072

[HeaderSearch] Make sure we clear the mapped name from the LookupFileCacheInfo when we reset the start point.

rdar://16462455

llvm-svn: 205071

Canonicalise the default triple that is used on Windows.  This should hopefully
fix the MSVC buildbots.

llvm-svn: 205070

Improve -Wunreachable-code to provide a means to indicate code is intentionally marked dead via if((0)).

Taking a hint from -Wparentheses, use an extra '()' as a sigil that
a dead condition is intentionally dead.  For example:

  if ((0)) { dead }

When this sigil is found, do not emit a dead code warning.  When the
analysis sees:

  if (0)

it suggests inserting '()' as a Fix-It.

llvm-svn: 205069

of TemplateArgumentLocs. 'uint64_t' has higher alignment requirements than a
pointer on some platforms.

llvm-svn: 205068

Emit 32-bit register names instead of 64-bit register names if the target does
not have 64-bit general purpose registers.

<rdar://problem/14653996>

llvm-svn: 205067

default until we provide a work-around for warning
suppression.

llvm-svn: 205066

[SemaObjC] For the semantics of the designated-initializer attribute, consider that the ObjC interface of the class
includes its class extensions.

This is follow-up for rdar://16305347

llvm-svn: 205065

unless the macro comes from a system header

llvm-svn: 205064

Committed this by accident before it was done last time.

Original message:

    Rather than rolling our own functions to read little endian data
    from a buffer, we can use the support in llvm's Endian.h.

    No functional change.

llvm-svn: 205062

Committed this by accident before it was done last time.

Original message:

    Rather than rolling our own functions to write little endian data
    to an ostream, we can use the support in llvm's EndianStream.h.

    No functional change.

llvm-svn: 205061

for expression evaluations that try one and then all threads.

<rdar://problem/15598528>

llvm-svn: 205060

Turns out debug_frame does use multiple fragments, so it doesn't
compress correctly with the current approach. Disable compressing it for
now while I figure out what's the best solution for it.

llvm-svn: 205059

WinCOFF cannot form PC relative relocations to support absolute
MCValues.  We should reenable this once WinCOFF supports emission of
IMAGE_REL_I386_REL32 relocations.

This fixes PR19272.

llvm-svn: 205058

llvm-svn: 205057

llvm-svn: 205056

Patch by: Jeroen Ketema

llvm-svn: 205055

Patch by: Jeroen Ketema

llvm-svn: 205054

llvm-svn: 205053

Also remove unused vector.

llvm-svn: 205052

llvm-svn: 205051

This is a bit of a stab in the dark, since I have zlib on my machine.
Just going to bounce it off the bots & see if it sticks.

Do we have some convention for negative REQUIRES: checks? Or do I just
need to add a feature like I've done here?

llvm-svn: 205050

The test was failing because clang-cl changes the default triple
to target MSVC-style Win32. This is kind of wonky, but hasn't been
a problem until we started warning:

  warning: unknown platform, assuming -mfloat-abi=soft

Some of the tests in cl-options.c were running with -Werror, causing them
to fail.

Fixing this by FileCheck-ifying those tests instead of using -Werror.

llvm-svn: 205049

This reverts commit r205045.

llvm-svn: 205048

This reverts commit r205044.

llvm-svn: 205047

Not only did I invert the indices when I wrote the code, but I also did the
same thing when I wrote the regression test. Oops.

llvm-svn: 205046

Rather than rolling our own functions to read little endian data from
a buffer, we can use the support in llvm's Endian.h.

No functional change.

llvm-svn: 205045

Rather than rolling our own functions to write little endian data to
an ostream, we can use the support in llvm's EndianStream.h.

No functional change.

llvm-svn: 205044