DebugInfo: Emit relocation to debug_line section when emitting asm for asm

I don't think this is reachable by any frontend (why would you transform
asm to asm+debug info?) but it helps tidy up some of this code, avoid
the weird special case of "emit the first CU, store the label, then emit
the rest" in MCDwarfLineTable::Emit by instead having the
DWARF-for-assembly case use the same codepath as DwarfDebug.cpp, by
registering the label of the debug_line section, thus causing it to be
emitted. (with a special case in asm output to just emit the label since
asm output uses the .loc directives, etc, rather than the debug_loc
directly)

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

Remove FIXMEs. The scope of a Variable is always a lexical scope; there is
nothing to be gained from switching this over to a DIScopeRef.

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

LTO type uniquing: store the Decl field of a DIImportedEntity as a DIRef.
No other functionality changes, DIBuilder testcase is included in a paired
CFE commit.

This relaxes the assertion in isScopeRef to also accept subclasses of
DIScope.

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

Add a comment about type-uniquing ObjC types.

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

Comment to describe the debug_loc.dwo constants

Code review feedback from Eric Christopher on r204697

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

MCJIT: ensure that cygwin is identified properly

Cygwin is now a proper environment rather than an OS.  This updates the MCJIT
tests to avoid execution on Cygwin.  This fixes native cygwin tests.

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

Move partial/runtime unrolling late in the pipeline

The generic (concatenation) loop unroller is currently placed early in the
standard optimization pipeline. This is a good place to perform full unrolling,
but not the right place to perform partial/runtime unrolling. However, most
targets don't enable partial/runtime unrolling, so this never mattered.

However, even some x86 cores benefit from partial/runtime unrolling of very
small loops, and follow-up commits will enable this. First, we need to move
partial/runtime unrolling late in the optimization pipeline (importantly, this
is after SLP and loop vectorization, as vectorization can drastically change
the size of a loop), while keeping the full unrolling where it is now. This
change does just that.

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

lit: Set a base directory for compiler-rt tests

Setting this parameter enables llvm-lit to run on source directories for
compiler-rt test suites that implement magic in their lit.cfg.

<rdar://problem/16458307>

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

Revert "SLPVectorizer: Ignore users that are insertelements we can reschedule them"

This reverts commit r205018.

Conflicts:
lib/Transforms/Vectorize/SLPVectorizer.cpp
test/Transforms/SLPVectorizer/X86/insert-element-build-vector.ll

This is breaking libclc build.

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

Shifting into the sign bit is UB as discussed on IRC. Explicitly use the
BitWord type for the constants to avoid this.

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

[Stackmaps] Update the stackmap format to use 64-bit relocations for the function address and properly align all entries.

This commit updates the stackmap format to version 1 to indicate the
reorganizaion of several fields. This was done in order to align stackmap
entries to their natural alignment and to minimize padding.

Fixes <rdar://problem/16005902>

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

[X86] Adjust cost of FP_TO_UINT v4f64->v4i32 as well

Pretty obvious follow-on to r205159 to also handle conversion from double
besides float.

Fixes <rdar://problem/16373208>

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

R600/SI: Remove leftover pattern splitting 64-bit ors.

It's now matched to the scalar 64-bit or and split later if
necessary.'

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

Register allocator: set CSRFirstUseCost to 5 for ARM64.

A value of 5 means if we have a split or spill option that has a really
low cost (1 << 14 is the entry frequency), we will choose to spill
or split the really cold path before using a callee-saved register.

This gives us the performance benefit on SPECInt2k and is also conservative.

rdar://16162005

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

Change shouldSplitVectorElementType to better match the description.

Pass the entire vector type, and not just the element.

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

Fix MSVC warning.

This patch is to fix the following warning when compiled with MSVC 64 bit.

  warning C4334: '<<' : result of 32-bit shift implicitly converted to 64
  bits (was 64-bit shift intended?)

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

R600/SI: Implement shouldConvertConstantLoadToIntImm

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

Add an optional ability to expand larger BUILD_VECTORs with shuffles

This adds the ability to expand large (meaning with more than two unique
defined values) BUILD_VECTOR nodes in terms of SCALAR_TO_VECTOR and (legal)
vector shuffles. There is now no limit of the size we are capable of expanding
this way, although we don't currently do this for vectors with many unique
values because of the default implementation of TLI's
shouldExpandBuildVectorWithShuffles function.

There is currently no functional change to any existing targets because the new
capabilities are not used unless some target overrides the TLI
shouldExpandBuildVectorWithShuffles function. As a result, I've not included a
test case for the new functionality in this commit, but regression tests will
(at least) be added soon when I commit support for the PPC QPX vector
instruction set.

The benefit of committing this now is that it makes the
shouldExpandBuildVectorWithShuffles callback, which had to be added for other
reasons regardless, fully functional. I suspect that other targets will
also benefit from tuning the heuristic.

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

R600: Compute masked bits for min and max

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

Don't relocate with sections if there might be a paired relocation.

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

Revert: [mips] Rewrite MipsAsmParser and MipsOperand.' due to buildbot errors in lld tests.

It's currently unable to parse 'sym + imm' without surrounding parenthesis.

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

R600: Add BFE, BFI, and BFM intrinsics to help with writing tests.

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

R600: Add target nodes for BFM and BFI

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

ARM: fix typo

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

Now that this test is assembly, make the checks a bit stronger.

This will be used for a followup patch.

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

[PowerPC] Don't ever expand BUILD_VECTOR of v2i64 with shuffles

If we have two unique values for a v2i64 build vector, this will always result
in two vector loads if we expand using shuffles. Only one is necessary.

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

Add a TLI hook to control when BUILD_VECTOR might be expanded using shuffles

There are two general methods for expanding a BUILD_VECTOR node:
  1. Use SCALAR_TO_VECTOR on the defined scalar values and then shuffle
     them together.
  2. Build the vector on the stack and then load it.

Currently, we use a fixed heuristic: If there are only one or two unique
defined values, then we attempt an expansion in terms of SCALAR_TO_VECTOR and
vector shuffles (provided that the required shuffle mask is legal). Otherwise,
always expand via the stack. Even when SCALAR_TO_VECTOR is not legal, this
can still be a good idea depending on what tricks the target can play when
lowering the resulting shuffle. If the target can't do anything special,
however, and if SCALAR_TO_VECTOR is expanded via the stack, this heuristic
leads to sub-optimal code (two stack loads instead of one).

Because only the target knows whether the SCALAR_TO_VECTORs and shuffles for a
build vector of a particular type are likely to be optimial, this adds a new
TLI function: shouldExpandBuildVectorWithShuffles which takes the vector type
and the count of unique defined values. If this function returns true, then
method (1) will be used, subject to the constraint that all of the necessary
shuffles are legal (as determined by isShuffleMaskLegal). If this function
returns false, then method (2) is always used.

This commit does not enhance the current code to support expanding a
build_vector with more than two unique values using shuffles, but I'll commit
an implementation of the more-general case shortly.

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

[mips] Rewrite MipsAsmParser and MipsOperand.

Summary:
Highlights:
- Registers are resolved much later (by the render method).
  Prior to that point, GPR32's/GPR64's are GPR's regardless of register
  size. Similarly FGR32's/FGR64's/AFGR64's are FGR's regardless of register
  size or FR mode. Numeric registers can be anything.
- All registers are parsed the same way everywhere (even when handling
  symbol aliasing)
  - One consequence is that all registers can be specified numerically
    almost anywhere (e.g. $fccX, $wX). The exception is symbol aliasing
    but that can be easily resolved.
- Removes the need for the hasConsumedDollar hack
- Parenthesis and Bracket suffixes are handled generically
- Micromips instructions are parsed directly instead of going through the
  standard encodings first.
- rdhwr accepts all 32 registers, and the following instructions that previously
  xfailed now work:
    ddiv, ddivu, div, divu, cvt.l.[ds], se[bh], wsbh, floor.w.[ds], c.ngl.d,
    c.sf.s, dsbh, dshd, madd.s, msub.s, nmadd.s, nmsub.s, swxc1
- Diagnostics involving registers point at the correct character (the $)
- There's only one kind of immediate in MipsOperand. LSA immediates are handled
  by the predicate and renderer.

Lowlights:
- Hardcoded '$zero' in the div patterns is handled with a hack.
  MipsOperand::isReg() will return true for a k_RegisterIndex token
  with Index == 0 and getReg() will return ZERO for this case. Note that it
  doesn't return ZERO_64 on isGP64() targets.
- I haven't cleaned up all of the now-unused functions.
  Some more of the generic parser could be removed too (integers and relocs
  for example).
- insve.df needed a custom decoder to handle the implicit fourth operand that
  was needed to make it parse correctly. The difficulty was that the matcher
  expected a Token<'0'> but gets an Imm<0>. Adding an implicit zero solved this.

Reviewers: matheusalmeida, vmedic

Reviewed By: matheusalmeida

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

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

Disable each MachineFunctionPass for 'optnone' functions, unless that
pass normally runs at optimization level None, or is part of the
register allocation pipeline.

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

Two updated tests for MinGW 32 and 64 exception handling code generation.

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

[PowerPC] Correct P7 dispatch unit allocation for vector instructions

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

This patch fixes LTO's RecordStreamer so that it records symbols in the MCExpr
part of an asm .symver directive as being used. This prevents referenced
functions from being internalized and deleted.

Without the patch to LTOModule.cpp, the test case will produce the error:

LLVM ERROR: A @@ version cannot be undefined.

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

Support: generalise object type handling for Windows

This generalises the object file type parsing to all Windows environments.  This
is used by cygwin as well as MSVC environments for MCJIT.  This also makes the
triple more similar to Chandler's suggestion of a separate field for the object
file format.

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

PR19099 - revert r203483

Now that r205212 was committed, r203483 is no longer necessary; it was a
temporary workaround that only handled a small number of the problematic cases.

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

ARM: change parameter names of the ELFARMAsmBackend constructor

I removed the underscore at the beginning of the parameter name,
because of a comment from Tim.

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

Test commit.

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

[mips] Fix use of uninitialized value reported by the sanitizer-x86_64-linux-bootstrap buildbot

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

Fix for PR19099 - NVPTX produces invalid symbol names.

This is a more thorough fix for the issue than r203483. An IR pass will run
before NVPTX codegen to make sure there are no invalid symbol names that can't
be consumed by the ptxas assembler.

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

ARM64: add extra patterns for scalar shifts

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

ARM64: add extra scalar neg pattern & tests.

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

ARM64: add patterns for scalar sqdmlal & sqdmlsl.

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

ARM64: add more patterns for commuted fmsub operations.

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

ARM64: shuffle patterns around for fmin/fmax & add tests.

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

ARM64: add more scalar patterns for usqadd & suqadd.

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

ARM64: add more scalar patterns for reciprocal ops.

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

ARM64: add i64 scalar pattern for @llvm.arm64.abs

This will be used by the Clang front-end code for vabsd_s64.

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

[mips] Implement missing relocations in the integrated assembler.

%got_hi, %got_lo, %call_hi, %call_lo, %higher, and %highest are now recognised
by MipsAsmParser::getVariantKind().

To prevent future issues with missing entries in this StringSwitch, I've added
an assertion to the default case.

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

[mips] Remove R_MIPS_GOT which isn't used and shares the same number as R_MIPS_GOT16

Unlike my previous commit, don't try to remove the corresponding VK_Mips_GOT yet
even though it shares the same assembly text since that is used.

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

Revert r205194 - [mips] Removed R_MIPS_GOT. It's identical to   R_MIPS_GOT16.

There's a couple additional bits I missed.

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

[mips] Removed R_MIPS_GOT. It's identical to R_MIPS_GOT16.

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

Capitalize the D in parseDirectiveGpDWord.

DWord seems to be the canonical way to camel case dword in llvm.

Thanks to Daniel Sander for noticing.

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

Remove unused private typedef

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

R600/SI: Implement SIInstrInfo::isTriviallyRematerializable()

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

R600/SI: Lower i64 SELECT by bitcasting to a vector type

This allows allows us to replace ISD::EXTRACT_ELEMENT, which is lowered
using shifts, with ISD::EXTRACT_VECTOR_ELT, which is a no-op.

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

R600/SI: Return the correct index for VGPRs in getHWRegIndex()

The register index is stored in the low 8-bits of the encoding.

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

Fixed issue with microMIPS JAL instruction.
Differential Revision: http://llvm-reviews.chandlerc.com/D3200

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

llvm/test/MC/Mips/mips64r2/valid-xfail.s: This REQUIRES asserts. Seems it doesn't fail with -Asserts.

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

[mips] Added a full set of instruction test cases for all ISA's (but not ASE's).

Summary:
Where those ISA's are not currently supported, the test is run with the smallest
superset of that ISA.

Some instructions are valid but don't pass yet. These have been placed in the
valid-xfail.s's which will XPASS if _any_ instruction starts working.

The valid.s's do not verify the encoding yet. There are also no tests checking that instructions from neighbouring ISA's are not accepted.

Reviewers: matheusalmeida

Reviewed By: matheusalmeida

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

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

Look at shuffles of build_vectors in DAGCombiner::visitEXTRACT_VECTOR_ELT

When the loop vectorizer vectorizes code that uses the loop induction variable,
we often end up with IR like this:

  %b1 = insertelement <2 x i32> undef, i32 %v, i32 0
  %b2 = shufflevector <2 x i32> %b1, <2 x i32> undef, <2 x i32> zeroinitializer
  %i = add <2 x i32> %b2, <i32 2, i32 3>

If the add in this example is not legal (as is the case on PPC with VSX), it
will be scalarized, and we'll end up with a number of extract_vector_elt nodes
with the vector shuffle as the input operand, and that vector shuffle is fed by
one or more build_vector nodes. By the time that vector operations are
expanded, visitEXTRACT_VECTOR_ELT will not create new extract_vector_elt by
looking through the vector shuffle (to make sure that no illegal operations are
created), and so the extract_vector_elt -> vector shuffle -> build_vector is
never simplified to an operand of the build vector.

By looking at build_vectors through a shuffle we fix this particular situation,
preventing a vector from being built, only to be deconstructed again (for the
scalarized add) -- an expensive proposition when this all needs to be done via
the stack. We probably want a more comprehensive fix here where we look back
recursively through any shuffles to any build_vectors or scalar_to_vectors,
etc. but that can come later.

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

[mips] Check emitted code for llvm.bswap.i32 on MIPS16/MIPS64 and llvm.bswap.i64 on MIPS16.

While reviewing r204163, I noticed that the MIPS16 test only checked for a .ent
directive and didn't actually check the code emitted. Fixed this and added a
check for llvm.bswap.i32 on MIPS64 at the same time.

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

ARM64: fix a couple of signed/unsigned comparison warnings.

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

[yaml2obj] Add support for ELF e_flags.

Summary:
The FileHeader mapping now accepts an optional Flags sequence that accepts
the EF_<arch>_<flag> constants. When not given, Flags defaults to zero.

Reviewers: atanasyan

Reviewed By: atanasyan

CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3213

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

Try to fix MSan bootstrap bot: make ARM64Disassembler::getInstruction() always initialize Size argument.

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

Correct OS conditionals following r204977 and r204978.

Previously, MinGW OS was Triple::MinGW and Cygwin was Triple::Cygwin
and now it is Triple::Win32 with Environment being GNU or Cygwin.
So,

  TheTriple.getOS() == Triple::Win32

is replaced by

  TheTriple.isWindowsMSVCEnvironment()

and

  (TheTriple.getOS() == Triple::MinGW32 || TheTriple.getOS() == Triple::Cygwin)

is replaced by

  TheTriple.isOSCygMing()

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

[C++11] Mark more classes in the X86 target as 'final'.

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

Mark a couple of the X86 target classes as final. Allows the compiler to de-virtualize some internal calls.

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

ARM64CollectLOH.cpp: Tweak \param. [-Wdocumentation]

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

[ARM64] Fix materialization of an fp128 zero immediate. There currently
is not a pattern to lower this with clever instructions that zero the
register, so restrict the zero immediate legality special case to f64
and f32 (the only two sizes which fmov seems to directly support). Fixes
backend errors when building code such as libxml.

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

[X86] Adjust cost of FP_TO_UINT v8f32->v8i32

There is no direct AVX instruction to convert to unsigned.  I have some ideas
how we may be able to do this with three vector instructions but the current
backend just bails on this to get it scalarized.

See the comment why we need to adjust the cost returned by BasicTTI.

The test is a bit roundabout (and checks assembly rather than bit code) because
I'd like it to work even if at some point we could vectorize this conversion.

Fixes <rdar://problem/16371920>

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

PR18929:
According to ARM assembler language hash symbol is optional before immediates.
For example, see here for more details:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473j/dom1359731154529.html

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

Make use of previously generated stores in SelectionDAGLegalize::ExpandExtractFromVectorThroughStack

When expanding EXTRACT_VECTOR_ELT and EXTRACT_SUBVECTOR using
SelectionDAGLegalize::ExpandExtractFromVectorThroughStack, we store the entire
vector and then load the piece we want. This is fine in isolation, but
generating a new store (and corresponding stack slot) for each extraction ends
up producing code of poor quality. When we scalarize a vector operation (using
SelectionDAG::UnrollVectorOp for example) we generate one EXTRACT_VECTOR_ELT
for each element in the vector. This used to generate one stored copy of the
vector for each element in the vector. Now we search the uses of the vector for
a suitable store before generating a new one, which results in much more
efficient scalarization code.

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

llvm/test/MC/ELF/nocompression.s: Loosen an expression to match "llvm-mc.EXE".

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

[PowerPC] Handle VSX v2i64 SIGN_EXTEND_INREG

sitofp from v2i32 to v2f64 ends up generating a SIGN_EXTEND_INREG v2i64 node
(and similarly for v2i16 and v2i8). Even though there are no sign-extension (or
algebraic shifts) for v2i64 types, we can handle v2i32 sign extensions by
converting two and from v2i64. The small trick necessary here is to shift the
i32 elements into the right lanes before the i32 -> f64 step. This is because
of the big Endian nature of the system, we need the i32 portion in the high
word of the i64 elements.

For v2i16 and v2i8 we can do the same, but we first use the default Altivec
shift-based expansion from v2i16 or v2i8 to v2i32 (by casting to v4i32) and
then apply the above procedure.

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

[Allocator] Lift the slab size and size threshold into template
parameters rather than runtime parameters.

There is only one user of these parameters and they are compile time for
that user. Making these compile time seems to better reflect their
intended usage as well.

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

[Allocator] Simplify unittests by using the default size parameters in
more places.

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

[Allocator] Stop forward-declaring BumpPtrAllocator in a few places.
This is a necessary step to lifting some of its configuration into
template parameters rather than runtime parameters.

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

Don't mark the declarations of the TSan annotation functions as weak.
That causes references to them to be weak references which can collapse
to null if no definition is provided. We call these functions
unconditionally, so a definition *must* be provided. Make the
definitions provided in the .cpp file weak by re-declaring them as weak
just prior to defining them. This should keep compilers which cannot
attach the weak attribute to the definition happy while actually
resolving the symbols correctly during the link.

You might ask yourself upon reading this commit log: how did *any* of
this work before? Well, fun story. It turns out we have some code in
Support (BumpPtrAllocator) which both uses virtual dispatch and has
out-of-line vtables used by that virtual dispatch. If you move the
virtual dispatch into its header in *just* the right way, the optimizer
gets to devirtualize, and remove all references to the vtable. Then the
sad part: the references to this one vtable were the only strong symbol
uses in the support library for llvm-tblgen AFAICT. At least, after
doing something just like this, these symbols stopped getting their weak
definition and random calls to them would segfault instead.

Yay software.

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

[ARM64] Fix a heap-use-after-free spotted by ASan.

StringRef::lower() returns a std::string. Better yet, we can now stop
thinking about what it returns and write 'auto'. It does the right
thing. =]

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

ARM64: uncopy/paste helper function

It was doing functional but highly suspect operations on bools due to
the more limited shifting operands supported by memory instructions.

Should fix some MSVC warnings.

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

ARM64: remove unused variables

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

ARM64: remove -m32/-m64 mapping with ARM.

This is causing the ARM build-bots to fail since they only include
the ARM backend and can't create an ARM64 target.

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

ARM64: override all the things.

Actually, mostly only those in the top-level directory that already
had a "virtual" attached. But it's the thought that counts and it's
been a long day.

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

Support: correct Windows normalisation

If the environment is unknown and no object file is provided, then assume an
"MSVC" environment, otherwise, set the environment to the object file format.

In the case that we have a known environment but a non-native file format for
Windows (COFF) which is used for MCJIT, then append the custom file format to
the triple as an additional component.

This fixes the MCJIT tests on Windows.

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

Suppress llvm/test/CodeGen/ARM64 for targeting pecoff. ARM64 is unaware of that.

FIXME: Could we support them?

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

llvm/test/Transforms/LoopStrengthReduce/ARM64/lsr-*.ll: Add explicit triple arm64-unknown for targeting pecoff.

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

X86Subtarget.h: isTargetWindows() should tell whether he is targeting msvc.

FYI, !isWindowsGNUEnvironment() is insufficient. It missed cygwin.

FIXME: The name "isTargetWindows" should be fixed.

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

[MC] Remove an unused (and broken) variant of the setupForSymbolicDisassembly
method in MCDisassembler.

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

[PBQP] Move invalid graph nodeId/edgeId methods into base class.

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

Add a missing break.

Patch by Tobias Güntner.

I tried to write a test, but the only difference is the Changed value that
gets returned. It can be tested with "opt -debug-pass=Executions -functionattrs,
but that doesn't seem worth it.

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

Support: normalize the default triple on Unix

This will fix cross-compiling buildbots (e.g. cygwin).  This is in the same vein
as SVN r205070.  Apply this to fix the cross-compiling scenario, even though the
preferred solution is to update the build system to normalize the embedded
triple rather than perform this at runtime every time.  This is meant to tide us
over until that approach is fleshed out and applied.

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

Remove dead declarations.

Patch by Tobias Güntner.

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

Remove outdated comment.

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

Fix a few -Wdocumentation warnings

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

Detemplatize LOHDirective.

The ARM64 backend uses it only as a container to keep an MCLOHType and
Arguments around so give it its own little copy. The other functionality
isn't used and we had a crazy method specialization hack in place to
keep it working. Unfortunately that was incompatible with MSVC.

Also range-ify a couple of loops while at it.

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

ARM64: Remove unused helper function, make others static.

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

tblgen: Twinify PrintFatalError.

No functionality change.

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

TableGen: don't save a StringRef to a local std::string.

This caused a failure in some Windows builds.

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

Avoid storing Twines.

While there nested ifs into a helper function. No functionality change.

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

[PowerPC] Handle v2i64 comparisons

v2i64 is a legal type under VSX, however we don't have native vector
comparisons. We can handle eq/ne by casting it to an Altivec type, but
everything else must be expanded.

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

ARM64: format register strings without creating a local Twine.

It was causing horrible failures on some build-bots.

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