ARM64 ended up reaching odder parts of TableGen alias generation than
current backends and caused a segfault.

llvm-svn: 205089

Some exotic types didn't know how to handle FROUND, which ARM64 uses.

llvm-svn: 205088

ARM64 has compact-unwind information, but doesn't necessarily want to
emit .eh_frame directives as well. This teaches MC about such a
situation so that it will skip .eh_frame info when compact unwind has
been successfully produced.

For functions incompatible with compact unwind, the normal information
is still written.

llvm-svn: 205087

Given IR like:
    %bit = and %val, #imm-with-1-bit-set
    %tst = icmp %bit, 0
    br i1 %tst, label %true, label %false

some targets can emit just a single instruction (tbz/tbnz in the
AArch64 case). However, with ISel acting at the basic-block level, all
three instructions need to be together for this to be possible.

This adds another transformation to CodeGenPrep to expose these
opportunities, if targets opt in via the hook.

llvm-svn: 205086

This is principally to allow neater mapping of fixups to relocations
in ARM64 ELF. Without this, there isn't enough information available
to GetRelocType, leading to many more fixup_arm64_... enumerators.

llvm-svn: 205085

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