[x86] Cleanup an unused variable by actually using it in the non-asserts
place where it was needed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217854 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Remove a FIXME that doesn't make any sense. Only the lanes feeding
the blend that is matched by this are "used" in any sense, and so any
build_vector or other nodes feeding these will already drop other lanes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217855 91177308-0d34-0410-b5e6-96231b3b80d8
tweak test case to help solve why failing on one build bot

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

Teach yaml2obj how to make a bigobj COFF file.  Like the rest of LLVM,
we automatically decide whether or not to use regular COFF or bigobj
COFF on the fly depending on how many sections the resulting object
would have.

This ends the task of adding bigobj support to LLVM.

N.B. This was tested by forcing yaml2obj to be used in bigobj mode
regardless of the number of sections.  While a dedicated test was
written, the smallest I could make it was 36 MB (!) of yaml and it still
took a significant amount of time to execute on a powerful machine.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217858 91177308-0d34-0410-b5e6-96231b3b80d8
Fix BasicTTI::getCmpSelInstrCost to deal with illegal vector types

The default implementation of getCmpSelInstrCost, which provides the cost of
icmp/fcmp/select instructions, did not deal sensibly with illegal vector types
that were scalarized. We'd ask for the legalization cost of the vector type,
which would return something like (4, f64) given an input of <4 x double>, and
we'd then check the TLI status of the ISD opcode on that scalar type. This would
result in querying (ISD::VSELECT, f64), for example. Amusingly enough,
ISD::VSELECT on scalar types is marked as Legal by default (as with most other
operations), and most backends never change this because VSELECT is never
generated on scalars. However, seeing the resulting operation as Legal, we'd
neglect to add the scalarization cost before returning. The result is that we'd
grossly under-estimate the cost of cmps/selects on illegal vector types.

Now, if type legalization clearly results in scalarization, we skip the early
return and add the scalarization cost.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217859 91177308-0d34-0410-b5e6-96231b3b80d8
tweak test case to help build bot

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217860 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-cov: Rename a variable and clean up its usage

Offset is a terrible name for an indentation / nesting level, and it
confuses me every time I look at this code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217861 91177308-0d34-0410-b5e6-96231b3b80d8
AVX-512: added cost for some AVX-512 instructions


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217863 91177308-0d34-0410-b5e6-96231b3b80d8
[InstCombine] Remove redundant test case.

Patch by Sonam Kumari!

Differential Revision: http://reviews.llvm.org/D5284

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217865 91177308-0d34-0410-b5e6-96231b3b80d8
ARMAsmBackend uses a factory method to generate binary file format specific
objects.  There were a few FIXMEs in ARMAsmBackend.cpp suggesting the class
definitions should be in a separate file.  Starting with ARMAsmBackend, the
class definition has been put in a header file, and #includes reduced.  Each
sub-type of ARMAsmBackend is now in its own header file.

Derived types have been painted with a different color of bike-shed:

  s/DarwinARMAsmBackend/ARMAsmBackendDarwin/g
  s/ARMWinCOFFAsmBackend/ARMAsmBackendWinCOFF/g
  s/ELFARMAsmBackend/ARMAsmBackendELF/g

Finally, clang-format has been run across ARMAsmBackend.cpp



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217866 91177308-0d34-0410-b5e6-96231b3b80d8
[mips] Marked the ADDi instruction aliases as not available in Mips32R6 and Mips64R6.

Patch by Vasileios Kalintiris.

Differential Revision: http://reviews.llvm.org/D5242



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217867 91177308-0d34-0410-b5e6-96231b3b80d8
[mips] Move 32-bit ADDiu instruction alias from Mips64InstrInfo.td to MipsInstrInfo.td.

Patch by Vasileios Kalintiris.

Differential Revision: http://reviews.llvm.org/D5244



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217868 91177308-0d34-0410-b5e6-96231b3b80d8
Make DWARFUnitSection final and change base class to non-virtual protected destructor.

As per dblaikie suggestion.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217871 91177308-0d34-0410-b5e6-96231b3b80d8
[mips] Improve the error messages given by MipsAsmParser.

Summary: Changed error messages to be more informative and to resemble other clang/llvm error messages (first letter is lower case, no ending punctuation) and updated corresponding tests.

Reviewers: dsanders

Reviewed By: dsanders

Differential Revision: http://reviews.llvm.org/D5065

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217873 91177308-0d34-0410-b5e6-96231b3b80d8
Interpreter: Hack around a series of bugs in MSVC 2012 that copies around this
move-only struct.

I feel terrible now, but at least it's shielded away from proper compilers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217875 91177308-0d34-0410-b5e6-96231b3b80d8
Spell out a move ctor. Even the 2013 vintage of MSVC cannot synthesize move ctors.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217879 91177308-0d34-0410-b5e6-96231b3b80d8
ARM load/store optimizer: Don't materialize a new base register with
ADDS/SUBS unless it's safe to clobber the condition flags.

If the merged instructions are in a range where the CPSR is live,
e.g. between a CMP -> Bcc, we can't safely materialize a new base
register.

This problem is quite rare, I couldn't come up with a test case and I've
never actually seen this happen in the tests I'm running - there is a
potential trigger for this in LNT/oggenc (spills being inserted between
a CMP/Bcc), but at the moment this isn't being merged. I'll try to
reduce that into a small test case once I've committed my upcoming patch
to make merging less conservative.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217881 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Improve comment

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217885 91177308-0d34-0410-b5e6-96231b3b80d8
[TableGen] Fully resolve class-instance values before defs in multiclasses

By class-instance values I mean 'Class<Arg>' in 'Class<Arg>.Field' or in
'Other<Class<Arg>>' (syntactically s SimpleValue).  This is to differentiate
from unnamed/anonymous record definitions (syntactically an ObjectBody) which
are not affected by this change.

Consider the testcase:

    class Struct<int i> {
      int I = !shl(i, 1);
      int J = !shl(I, 1);
    }

    class Class<Struct s> {
        int Class_J = s.J;
    }

    multiclass MultiClass<int i> {
      def Def : Class<Struct<i>>;
    }

    defm Defm : MultiClass<2>;

Before this fix, DefmDef.Class_J yields !shl(I, 1) instead of 8.

This is the sequence of events.  We start with this:

    multiclass MultiClass<int i> {
      def Def : Class<Struct<i>>;
    }

During ParseDef the anonymous object for the class-instance value is created:

    multiclass Multiclass<int i> {
      def anonymous_0 : Struct<i>;

      def Def : Class<NAME#anonymous_0>;
    }

Then class Struct<i> is added to anonymous_0.  Also Class<NAME#anonymous_0> is
added to Def:

    multiclass Multiclass<int i> {
      def anonymous_0 {
        int I = !shl(i, 1);
        int J = !shl(I, 1);
      }

      def Def {
        int Class_J = NAME#anonymous_0.J;
      }
    }

So far so good but then we move on to instantiating this in the defm
by substituting the template arg 'i'.

This is how the anonymous prototype looks after fully instantiating.

    defm Defm = {
      def Defmanonymous_0 {
         int I = 4;
         int J = !shl(I, 1);
      }

Note that we only resolved the reference to the template arg.  The
non-template-arg reference in 'J' has not been resolved yet.

Then we go on to instantiating the Def prototype:

      def DefmDef {
         int Class_J = NAME#anonymous_0.J;
      }

Which is resolved to Defmanonymous_0.J and then to !shl(I, 1).

When we fully resolve each record in a defm, Defmanonymous_0.J does get set
to 8 but that's too late for its use.

The patch adds a new attribute to the Record class that indicates that this
def is actually a class-instance value that may be *used* by other defs in a
multiclass.  (This is unlike regular defs which don't reference each other and
thus can be resolved indepedently.)  They are then fully resolved before the
other defs while the multiclass is instantiated.

I added vg_leak to the new test.  I am not sure if this is necessary but I
don't think I have a way to test it.  I can also check in without the XFAIL
and let the bots test this part.

Also tested that X86.td.expanded and AAarch64.td.expanded were unchange before
and after this change.  (This issue triggering this problem is a WIP patch.)

Part of <rdar://problem/17688758>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217886 91177308-0d34-0410-b5e6-96231b3b80d8
Fix move-only type issues in Interpreter with MSVC

MSVC 2012 cannot infer any move special members, but it will call them
if available. MSVC 2013 cannot infer move assignment. Therefore,
explicitly implement the special members for the ExecutionContext class
and its contained types.

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