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

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

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

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

llvm-svn: 205070

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

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: 205053

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

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

Unfortunately this one fails deep inside the mips backend, so xfail it.

llvm-svn: 205042

v2[fi]64 values need to be explicitly passed in VSX registers. This is because
the code in TRI that finds the minimal register class given a register and a
value type will assert if given an Altivec register and a non-Altivec type.

llvm-svn: 205041

llvm-svn: 205040

llvm-svn: 205039

It was using "lc  -filetype=obj" just to pass the result to
"llvm-objdupm -disassemble" and then filecheck assembly.

The CHECK-NOT would never match anyway since it was missing $.

llvm-svn: 205036

llvm-svn: 205033

This adds a new header, EndianStream.h, which supplies an adaptor for
writing endian specific data to a raw_ostream.

llvm-svn: 205032

With that, convert another llc -filetype=obj test.

llvm-svn: 205031

llvm-svn: 205028

llvm-svn: 205027

llvm-svn: 205026

Extract element instructions that will be removed when vectorzing lower the
cost.

Patch by Arch D. Robison!

llvm-svn: 205020

Patch by Arch D. Robison!

llvm-svn: 205019

Patch by Arch D. Robison!

llvm-svn: 205018

The non-SJLJ and SJLJ intrinsics are generated by the frontend and
backend respectively.

Differential Revision: http://llvm-reviews.chandlerc.com/D3010

llvm-svn: 205017

I'll implement error handling and a negative test in both llvm-mc and
Clang soon.

llvm-svn: 205016

llvm-svn: 205014

llvm-svn: 205013

This reverts commit r204912, and follow-up commit r204948.

This introduced a performance regression, and the fix is not completely
clear yet.

llvm-svn: 205010

This reverts commit r203553, and follow-up commits r203558 and r203574.

I will follow this up on the mailinglist to do it in a way that won't
cause subtle PRE bugs.

llvm-svn: 205009

Reviewed at http://llvm-reviews.chandlerc.com/D3095

llvm-svn: 205007