[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
Test commit.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205214 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
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
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
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
[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
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
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
[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
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
[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
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
ARM: fix typo

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205233 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
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
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
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
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
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