Allow pinsrw/pinsrb/pextrb/pextrw/movmskps/movmskpd/pmovmskb/extractps instructions to parse either GR32 or GR64 without resorting to duplicating instructions.

llvm-svn: 192567

Add disassembler support for SSE4.1 register/register form of PEXTRW. There is a shorter encoding that was part of SSE2, but a memory form was added in SSE4.1. This is the register form of that encoding.

llvm-svn: 192566

Mark MOVMSKPS/MOVMSKPD/VPINSRWrr64i as AsmParserOnly to remove them from the disassembler tables. Add PINSRWrr64i to complement the AVX version.

llvm-svn: 192565

llvm-svn: 192564

Summary:
Store IndentationLevel in ParentState and use it instead of the
Line::Level when indening.
Also fixed incorrect indentation level calculation in formatFirstToken.

Reviewers: djasper

Reviewed By: djasper

CC: cfe-commits, klimek

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

llvm-svn: 192563

Don't use 64-bit versions of MOVMSKPD in CodeGen. The instructions only produce a 1-bit result so we can just use SUBREG_TO_REG to extend the 32-bit versions.

llvm-svn: 192562

We don't delay load it so it shouldn't be going anywhere.

llvm-svn: 192561

llvm-svn: 192560

an accidentally-included name for the declarator.

llvm-svn: 192559

This can happen when processing command line arguments, which
are often stored as std::string's and later turned into
StringRef's via std::string::data().  Unfortunately this
is not guaranteed to return a null-terminated string
until C++11, causing breakage on platforms that don't do this.

llvm-svn: 192558

llvm-svn: 192557

llvm-svn: 192556

llvm-svn: 192555

llvm-svn: 192554

llvm-svn: 192553

It makes apparently no change it to set this bit or not but the
docs recommand to left it cleared.

llvm-svn: 192552

llvm-svn: 192551

We were using an anti-pattern of:
 - LoadLibrary
 - GetProcAddress
 - FreeLibrary

This is problematic because of several reasons:
 - We are holding on to pointers into a library we just unloaded.
 - Calling LoadLibrary results in an increase in the reference count of
   the library in question and any libraries that it depends on and
   so-on and so-forth.  This is none too quick.

Instead, use GetModuleHandleEx with GET_MODULE_HANDLE_EX_FLAG_PIN.  This
is done because because we didn't bring the reference for the library
into existence and therefor shouldn't count on it being around later.

llvm-svn: 192550

(This is triggered by current lit tests)

llvm-svn: 192549

Patch from GM to make more implicit bools explicit since we can't stop MSVC warning about this in headers and to warn is the MSVC default. No functionality change.

llvm-svn: 192548

If the edit distance between the two macros is more than 50%, DefinedMacro may not be header guard or can be header guard of another header file or it might be defining something completely different set by the build environment.

llvm-svn: 192547

llvm-svn: 192546

llvm-svn: 192545

llvm-svn: 192544

While it is mostly a user error to have the extra semicolon,
formatting it graciously will correctly format in the cases
where we do not fully understand the code (macros).

llvm-svn: 192543

* std::string::append(int, int) can be ambiguous.
* std::vector<>::data() is a C++11 feature, use ArrayRef abstraction.

llvm-svn: 192542

llvm-svn: 192541

llvm-svn: 192540

llvm-svn: 192539

llvm-svn: 192538

Before this patch we relied on the order of phi nodes when we looked for phi
nodes of the same type. This could prevent vectorization of cases where there
was a phi node of a second type in between phi nodes of some type.

This is important for vectorization of an internal graphics kernel. On the test
suite + external on x86_64 (and on a run on armv7s) it showed no impact on
either performance or compile time.

radar://15024459

llvm-svn: 192537

Contributed-by: Peter Zotov <whitequark@whitequark.org>
llvm-svn: 192536

llvm-svn: 192535

llvm-svn: 192534

llvm-svn: 192533

llvm-svn: 192532

Patch from Rami Ylimäki and Mikael Lepistö!

llvm-svn: 192531

llvm-svn: 192530

llvm-svn: 192527

llvm-svn: 192525