[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

[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

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

tweak test case for debugging bot

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

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

Fix typo

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

[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

[X86] Improve comment

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

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

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

[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

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] 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

[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

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

[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

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

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

tweak test case to help build bot

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

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

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

[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

[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

[llvm-objdump] for mach-o add -bind, -lazy-bind, and -weak-bind options

This finishes the ability of llvm-objdump to print out all information from
the LC_DYLD_INFO load command.

The -bind option prints out symbolic references that dyld must resolve
immediately.

The -lazy-bind option prints out symbolc reference that are lazily resolved on
first use.

The -weak-bind option prints out information about symbols which dyld must
try to coalesce across images.

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

[x86] Remove the last vestiges of the BLENDI-based ADDSUB pattern
matching. This design just fundamentally didn't work because ADDSUB is
available prior to any legal lowerings of BLENDI nodes. Instead, we have
a dedicated ADDSUB synthetic ISD node which is pattern matched trivially
into the instructions. These nodes are then recognized by both the
existing and a trivial new lowering combine in the backend. Removing
these patterns required adding 2 missing shuffle masks to the DAG
combine, without which tests would have failed. Added the masks and
a helpful assert as well to catch if anything ever goes wrong here.

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

[FastISel][AArch64] Add vector support to argument lowering.

Lower the first 8 vector arguments too.

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

[x86] As a follow-up to r217819, don't check for VSELECT legality now
that we don't use VSELECT and directly emit an addsub synthetic node.
Also remove a stale comment referencing VSELECT.

The test case is updated to use 'core2' which only has SSE3, not SSE4.1,
and it still passes. Previously it would not because we lacked
sufficient blend support to legalize the VSELECT.

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

[x86] Add the beginnings of a proper DAG combine to match ADDSUBPS and
ADDSUBPD nodes out of blends of adds and subs.

This allows us to actually form these instructions with SSE3 rather than
only forming them when we had both SSE3 for the ADDSUB instructions and
SSE4.1 for the blend instructions. ;] Kind-of important.

I've adjusted the CPU requirements on one of the tests to demonstrate
this kicking in nicely for an SSE3 cpu configuration.

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

[FastISel][AArch64] Add missing test case for previous commit.

This adds the missing test case for the previous commit:
Allow handling of vectors during return lowering for little endian machines.

Sorry for the noise.

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

[FastISel][AArch64] Allow handling of vectors during return lowering for little endian machines.

Allow handling of vectors during return lowering at least for little endian machines.
This was restricted in r208200 to fix it for big endian machines (according to
the comment), but it also disabled it for little endian too.

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

[FastISel][AArch64] Update function and variable names to follow the coding standard. NFC.

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

DebugInfo: Add comment describing the need to disable address pool usage in skeleton units.

Post commit review from Eric Christopher.

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

[FastISel][AArch64] Make AArch64FastISel class final. NFC.

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

[FastISel][AArch64] Lower sin/cos/pow to runtime lib calls.

Also lower sin/cos/pow to runtime lib calls.

This fixes rdar://problem/18343468.

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

llvm-cov: Make debug output more consistent

This changes the debug output of the llvm-cov tool to consistently
write to stderr, and moves the highlighting output closer to where
it's relevant.

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

Fix indenting caused by clang-format+spuriously indented access specifier in r216925

Caught in post-commit review by Justin Bogner.

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

llvm-cov: Fix an issue with showing regions but not counts

In r217746, though it was supposed to be NFC, I broke llvm-cov's
handling of showing regions without showing counts. This should've
shown up in the existing tests, except they were checking debug output
that was displayed regardless of what was actually output. I've moved
the relevant debug output to a more appropriate place so that the
tests catch this kind of thing.

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

Add back tests for empty function in SPARC and PowerPC.

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

[FastISel][AArch64] Add lowering support for frem.

This lowers frem to a runtime libcall inside fast-isel.

The test case also checks the CallLoweringInfo bug that was exposed by this
change.

This fixes rdar://problem/18342783.

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

[FastISel] Fix a bug in FastISel::CallLoweringInfo.

This fixes a bug in FastISel::CallLoweringInfo, where the number of
arguments was obtained from the argument vector before it had been
initialized.

Test case follows in another commit.

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

Replace repeated null checks with an assert. NFC.

Without a vector to hold the created ops, these
functions don't have any use.

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

[Support] add decodeSLEB128()

We already have routines to encode SLEB128 as well as encode/decode ULEB128.
This last function fills out the matrix.  I'll need this for some llvm-objdump
work I am doing.

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

[FastISel][AArch64] Refactor selectAddSub, selectLogicalOp, and SelectShift. NFC.

Small refactor to tidy up the code a little.

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

[FastISel][AArch64] Refactor code to use isTypeSupported. NFC.

Gets rid of isLoadStoreTypeLegal and replace it with isTypeSupported.

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

Remove dead code in SimplifyCFG

Summary: UsedByBranch is always true according to how BonusInst is defined.

Test Plan:
Passes check-all, and also verified

if (BonusInst && !UsedByBranch) {
  ...
}

is never entered during check-all.

Reviewers: resistor, nadav, jingyue

Reviewed By: jingyue

Subscribers: llvm-commits, eliben, meheff

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

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

[FastISel][AArch64] Improve floating-point compare support.

Add support for the last two missing fcmp condition codes: UEQ and ONE.

This fixes rdar://problem/18341575.

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

[FastISel] Move optimizeCmpPredicate to FastISel base class. NFC.

Make the optimizeCmpPredicate function available to all targets.

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

Add mips32 r1 to the list of supported targets for Mips fast-isel

Summary:
Expand list of supported targets for Mips to include mips32 r1.
Previously it only include r2. More patches are coming where there is
a difference but in the current patches as pushed upstream, r1 and r2
are equivalent.

Test Plan:
simplestorefp1.ll

add new build bots at mips to test this flavor at both -O0 and -O2

Reviewers: dsanders

Reviewed By: dsanders

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

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

Fix the build for MSVC, it doesn't support extended sizeof

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

[x86] Start fixing our emission of ADDSUBPS and ADDSUBPD instructions by
introducing a synthetic X86 ISD node representing this generic
operation.

The relevant patterns for mapping these nodes into the concrete
instructions are also added, and a gnarly bit of C++ code in the
target-specific DAG combiner is replaced with simple code emitting this
primitive.

The next step is to generically combine blends of adds and subs into
this node so that we can drop the reliance on an SSE4.1 ISD node
(BLENDI) when matching an SSE3 feature (ADDSUB).

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

Replace dead links to "Hacker's Delight" with general references. NFC.

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

MC: Add support for BigObj

Teach WinCOFFObjectWriter how to write -mbig-obj style object files;
these object files allow for more sections inside an object file.

Our support for BigObj is notably different from binutils and cl: we
implicitly upgrade object files to BigObj instead of asking the user to
compile the same file *again* but with another flag.  This matches up
with how LLVM treats ELF variants.

This was tested by forcing LLVM to always emit BigObj files and running
the entire test suite.  A specific test has also been added.

I've lowered the maximum number of sections in a normal COFF file,
VS "14" CTP 3 supports no more than 65279 sections.  This is important
otherwise we might not switch to BigObj quickly enough, leaving us with
a COFF file that we couldn't link.

yaml2obj support is all that remains to implement.

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

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

Add return that was lost somehow in my last commit.

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

Remove ancient hack that was emulating move semantics with reference counting.

No functionality change.

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

llvm/test/CodeGen/X86/peephole-fold-movsd.ll: Relax an expression for win32.

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

Add a triple to fix the bots.

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

Fix memory leak in error paths in YAMLTraits by using unique_ptr

There's some other cleanup that could happen here, but this is at least
the mechanical transformation to unique_ptr.

Derived from a patch by Anton Yartsev.

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

Fix a lot of confusion around inserting nops on empty functions.

On MachO, and MachO only, we cannot have a truly empty function since that
breaks the linker logic for atomizing the section.

When we are emitting a frame pointer, the presence of an unreachable will
create a cfi instruction pointing past the last instruction. This is perfectly
fine. The FDE information encodes the pc range it applies to. If some tool
cannot handle this, we should explicitly say which bug we are working around
and only work around it when it is actually relevant (not for ELF for example).

Given the unreachable we could omit the .cfi_def_cfa_register, but then
again, we could also omit the entire function prologue if we wanted to.

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

[CodeGenPrepare][AddressingModeMatcher] Fix a think-o for the sext(zext) -> zext promotion
introduced in r217629.
We were returning the old sext instead of the new zext as the promoted instruction!

Thanks Joerg Sonnenberger for the test case.

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

[X86] Fix a bug in X86's peephole optimization.

Peephole optimization was folding MOVSDrm, which is a zero-extending double
precision floating point load, into ADDPDrr, which is a SIMD add of two packed
double precision floating point values.

(before)
%vreg21<def> = MOVSDrm <fi#0>, 1, %noreg, 0, %noreg; mem:LD8[%7](align=16)(tbaa=<badref>) VR128:%vreg21
%vreg23<def,tied1> = ADDPDrr %vreg20<tied0>, %vreg21; VR128:%vreg23,%vreg20,%vreg21

(after)
%vreg23<def,tied1> = ADDPDrm %vreg20<tied0>, <fi#0>, 1, %noreg, 0, %noreg; mem:LD8[%7](align=16)(tbaa=<badref>) VR128:%vreg23,%vreg20

X86InstrInfo::foldMemoryOperandImpl already had the logic that prevented this
from happening. However the check wasn't being conducted for loads from stack
objects. This commit factors out the logic into a new function and uses it for
checking loads from stack slots are not zero-extending loads.

rdar://problem/18236850

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

CHECK-LABELize test

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

Use dyn_cast<> instead of isa<> and cast<>

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

[MCJIT] Start Stringref-izing the ExecutionEngine interface.

More methods to follow.

Using StringRef allows us the EE interface to work with more string types
without forcing construction of std::strings.

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

R600/SI: Prefer selecting more e64 instruction forms.

Add some more tests to make sure better operand
choices are still made. Leave some cases that seem
to have no reason to ever be e64 alone.

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

R600/SI: Make sure double vector fmul is tested

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

Add unit test for r217454

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

R600/SI: Add some mubuf testcases.

I noticed some odd looking cases where addr64 wasn't set
when storing to a pointer in an SGPR. This seems to be intentional,
and partially tested already.

The documentation seems to describe addr64 in terms of which registers
addressing modifiers come from, but I would expect to always need
addr64 when using 64-bit pointers. If no offset is applied,
it makes sense to not need to worry about doing a 64-bit add
for the final address. A small immediate offset can be applied,
so is it OK to not have addr64 set if a carry is necessary when adding
the base pointer in the resource to the offset?

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

Spell out the template args for compilers having issues with the injected class
name.

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

Use IntrusiveRefCntPtr to manage the lifetime of BitCodeAbbrevs.

This doesn't change the interface or gives additional safety but removes
a ton of retain/release boilerplate.

No functionality change.

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

R600/SI: Add preliminary support for flat address space

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

R600/SI: Fix promote alloca pass breaking addrspacecast

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

R600/SI: Enable named operand table for MTBUF

There is already code trying to use it for getting
the offset.

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

[mips] Use early exit in MipsAsmParser::matchCPURegisterName(). NFC.

Patch by Vasileios Kalintiris.

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

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

[mips] Marked the DADDiu instruction aliases as MIPS III.

Patch by Vasileios Kalintiris.

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

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

[x86] Begin emitting PBLENDW instructions for integer blend operations
when SSE4.1 is available.

This removes a ton of domain crossing from blend code paths that were
ending up in the floating point code path.

This is just the tip of the iceberg though. The real switch is for
integer blend lowering to more actively rely on this instruction being
available so we don't hit shufps at all any longer. =] That will come in
a follow-up patch.

Another place where we need better support is for using PBLENDVB when
doing so avoids the need to have two complementary PSHUFB masks.

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

[x86] Add an explicit SSE3 run to this test and flesh out a bunch of
missing specific checks.

While there is a lot of redundancy here where all-but-one mode use the
same code generation, I'd rather have each variant spelled out and
checked so that readers aren't misled by an omission in the test suite.

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

[x86] Teach the x86 DAG combiner to form UNPCKLPS and UNPCKHPS
instructions from the relevant shuffle patterns.

This is the last tweak I'm aware of to generate essentially perfect
v4f32 and v2f64 shuffles with the new vector shuffle lowering up through
SSE4.1. I'm sure I've missed some and it'd be nice to check since v4f32
is amenable to exhaustive exploration, but this is all of the tricks I'm
aware of.

With AVX there is a new trick to use the VPERMILPS instruction, that's
coming up in a subsequent patch.

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

[x86] Teach the x86 DAG combiner to form MOVSLDUP and MOVSHDUP
instructions when it finds an appropriate pattern.

These are lovely instructions, and its a shame to not use them. =] They
are fast, and can hand loads folded into their operands, etc.

I've also plumbed the comment shuffle decoding through the various
layers so that the test cases are printed nicely.

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

Fix a non-virtual destructor warning introduced in r217747.

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

[x86] Undo a flawed transform I added to form UNPCK instructions when
AVX is available, and generally tidy up things surrounding UNPCK
formation.

Originally, I was thinking that the only advantage of PSHUFD over UNPCK
instruction variants was its free copy, and otherwise we should use the
shorter encoding UNPCK instructions. This isn't right though, there is
a larger advantage of being able to fold a load into the operand of
a PSHUFD. For UNPCK, the operand *must* be in a register so it can be
the second input.

This removes the UNPCK formation in the target-specific DAG combine for
v4i32 shuffles. It also lifts the v8 and v16 cases out of the
AVX-specific check as they are potentially replacing multiple
instructions with a single instruction and so should always be valuable.
The floating point checks are simplified accordingly.

This also adjusts the formation of PSHUFD instructions to attempt to
match the shuffle mask to one which would fit an UNPCK instruction
variant. This was originally motivated to allow it to match the UNPCK
instructions in the combiner, but clearly won't now.

Eventually, we should add a MachineCombiner pass that can form UNPCK
instructions post-RA when the operand is known to be in a register and
thus there is no loss.

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

[x86] Teach the new vector shuffle lowering to use 'punpcklwd' and
'punpckhwd' instructions when suitable rather than falling back to the
generic algorithm.

While we could canonicalize to these patterns late in the process, that
wouldn't help when the freedom to use them is only visible during
initial lowering when undef lanes are well understood. This, it turns
out, is very important for matching the shuffle patterns that are used
to lower sign extension. Fixes a small but relevant regression in
gcc-loops with the new lowering.

When I changed this I noticed that several 'pshufd' lowerings became
unpck variants. This is bad because it removes the ability to freely
copy in the same instruction. I've adjusted the widening test to handle
undef lanes correctly and now those will correctly continue to use
'pshufd' to lower. However, this caused a bunch of churn in the test
cases. No functional change, just churn.

Both of these changes are part of addressing a general weakness in the
new lowering -- it doesn't sufficiently leverage undef lanes. I've at
least a couple of patches that will help there at least in an academic
sense.

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

Fix ambiguous typedef introduced in r217747.

Use fully qualified name inside a typedef from llvm::iterator_range<...> to
iterator_range. This is reported (rightly I think) by GCC as an
ambiguous name redefinition. Hope this fixes the buildbots.

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

InstSimplify: Simplify trivial and/or of icmps

Some ICmpInsts when anded/ored with another ICmpInst trivially reduces
to true or false depending on whether or not all integers or no integers
satisfy the intersected/unioned range.

This sort of trivial looking code can come about when InstCombine
performs a range reduction-type operation on sdiv and the like.

This fixes PR20916.

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

Fix DebugInfo replaceAllUsesWith.

Summary:
replaceAllUsesWith had been modified to allow a DbgNode value to be
replaced by itself. In that case a new node is created by copying the
current DbgNode and the copy is used as replacement value.

When that copying happens, the value stored in this->DbgNode at the end
of RAUW would be a reference to the Node that has just been deleted.

This doesn't produce any bug right now, because the DI node on which we
call RAUW won't be used again.

Reviewers: dblaikie, echristo, aprantl

Subscribers: llvm-commits

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

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

Move replaceAllUsesWith() from DIType to DIDescriptor.

RAUW was only used on DIType to merge declarations and full definitions
of types. In order to support the same functionality for functions and
global variables, move the function up type DI type hierarchy to the
common parent of DIType, DISubprogram and DIVariable which is
DIDescriptor.

This functionality will be exercized when we add the code to emit
imported declarations for forward declared function/variables.

Reviewers: echristo, dblaikie, aprantl

Subscribers: llvm-commits

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

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

Introduce the DWARFUnitSection abstraction.

A DWARFUnitSection is the collection of Units that have been extracted from
the same debug section.

By embeding a reference to their DWARFUnitSection in each unit, the DIEs
will be able to resolve inter-unit references by interrogating their Unit's
DWARFUnitSection.

This is a minimal patch where the DWARFUnitSection is-a SmallVector of Units,
thus exposing exactly the same interface as before. Followup-up patches might
change from inheritance to composition in order to expose only the wanted
DWARFUnitSection abstraction.

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

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

llvm-cov: Clean up some redundancy in the view API (NFC)

This removes the need to pass a starting and ending line when creating
a SourceCoverageView, since these are easy to determine.

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

llvm-cov: Simplify CounterMappingRegion, pushing logic to its user

A single function in SourceCoverageDataManager was the only user of
some of the comparisons in CounterMappingRegion, and at this point we
know that only one file is relevant. This lets us use slightly simpler
logic directly in the client.

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

[x86] Teach the new vector shuffle lowering to use BLENDPS and BLENDPD.

These are super simple. They even take precedence over crazy
instructions like INSERTPS because they have very high throughput on
modern x86 chips.

I still have to teach the integer shuffle variants about this to avoid
so many domain crossings. However, due to the particular instructions
available, that's a touch more complex and so a separate patch.

Also, the backend doesn't seem to realize it can commute blend
instructions by negating the mask. That would help remove a number of
copies here. Suggestions on how to do this welcome, it's an area I'm
less familiar with.

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

llvm/test/CodeGen/X86/vec_shuffle-38.ll: Add explicit -mtriple=x86_64-unknown to avoid incompatibility of win32.

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

[x86] Add an SSE41 mode to this test. Nothing interesting here, its the
same as SSE3.

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

[x86] Switch this test to use an ALL prefix with special SSE2 and SSE3
variants where significant.

This will make it more obvious what is happening when we start using
blends in SSE41.

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

[x86] Add some test cases where we should emit blendpd in SSE4.1. No
actual change yet though.

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

[x86] Teach the vector combiner that picks a canonical shuffle from to
support transforming the forms from the new vector shuffle lowering to
use 'movddup' when appropriate.

A bunch of the cases where we actually form 'movddup' don't actually
show up in the test results because something even later than DAG
legalization maps them back to 'unpcklpd'. If this shows back up as
a performance problem, I'll probably chase it down, but it is at least
an encoded size loss. =/

To make this work, also always do this canonicalizing step for floating
point vectors where the baseline shuffle instructions don't provide any
free copies of their inputs. This also causes us to canonicalize
unpck[hl]pd into mov{hl,lh}ps (resp.) which is a nice encoding space
win.

There is one test which is "regressed" by this: extractelement-load.
There, the test case where the optimization it is testing *fails*, the
exact instruction pattern which results is slightly different. This
should probably be fixed by having the appropriate extract formed
earlier in the DAG, but that would defeat the purpose of the test.... If
this test case is critically important for anyone, please let me know
and I'll try to work on it. The prior behavior was actually contrary to
the comment in the test case and seems likely to have been an accident.

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

In DwarfEHPrepare, after all passes are run, RewindFunction may be a dangling
pointer to a dead function. To make sure it's valid, doFinalization nullptrs
RewindFunction just like the constructor and so it will be found on next run.

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