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
Add a missing return to operator=

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217892 91177308-0d34-0410-b5e6-96231b3b80d8
Hookup the MCSymbolizer to llvm-objdump’s disassembly for Mach-O files.

First step done in this commit is to get flush out enough of the
SymbolizerGetOpInfo() routine to symbolic an X86_64 hello world .o and
its loading of the literal string and call to printf.  Also the code to
symbolicate the X86_64_RELOC_SUBTRACTOR relocation and a test is also
added to show a slightly more complicated case.

Next will be to flush out enough of SymbolizerSymbolLookUp() to get the
literal string “Hello world” printed as a comment on the instruction that load
the pointer to it.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217893 91177308-0d34-0410-b5e6-96231b3b80d8
Add back a fallback case for targets that do not or cannot implement getNoopForMachoTarget().


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217899 91177308-0d34-0410-b5e6-96231b3b80d8
tweak test case for debugging bot

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217906 91177308-0d34-0410-b5e6-96231b3b80d8
This add a reset method for WinCOFFObjectWriter, like other MC* classes.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217907 91177308-0d34-0410-b5e6-96231b3b80d8
[llvm-objdump] improve error reporting of bad mach-o ordinals

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217909 91177308-0d34-0410-b5e6-96231b3b80d8
[CodeGenPrepare][AddressingModeMatcher] The promotion mechanism was expecting
instructions when truncate, sext, or zext were created. Fix that.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217926 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Use the generic AtomicExpandPass instead of X86AtomicExpandPass

This required a new hook called hasLoadLinkedStoreConditional to know whether
to expand atomics to LL/SC (ARM, AArch64, in a future patch Power) or to
CmpXchg (X86).

Apart from that, the new code in AtomicExpandPass is mostly moved from
X86AtomicExpandPass. The main result of this patch is to get rid of that
pass, which had lots of code duplicated with AtomicExpandPass.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217928 91177308-0d34-0410-b5e6-96231b3b80d8
[llvm-objdump] properly use c_str() with format("%s").  Improve getLibraryShortNameByIndex() error handling.





git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217930 91177308-0d34-0410-b5e6-96231b3b80d8
Fix identify_magic() with mach-o stub dylibs.

The wrong value was returned and the unittest did not cover the stub dylib case.




git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217933 91177308-0d34-0410-b5e6-96231b3b80d8
| -> ||
No functional change.


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