Our commands that end up displaying a ValueObject as part of their workflow use OptionGroupValueObjectDisplay as their currency for deciding the final representation
ValueObjects themselves use DumpValueObjectOptions as the currency for the same purpose

The code to convert between these two units was replicated (to varying degrees of correctness) in several spots in the code
This checkin provides one and only one (and hopefully correct :-) entry point for this conversion

llvm-svn: 178044

llvm-svn: 178043

machine and one is required.
Part of rdar://13295753

llvm-svn: 178042

- Add head 'prfchwintrin.h' to define '_m_prefetchw' which is mapped to
  LLVM/clang prefetch builtin
- Add option '-mprfchw' to enable PRFCHW feature and pre-define '__PRFCHW__'
  macro

llvm-svn: 178041

- Add 'PRFCHW' feature defined in AVX2 ISA extension

llvm-svn: 178040

llvm-svn: 178039

llvm-svn: 178038

[Preprocessor/Modules] Separate the macro directives kinds into their own MacroDirective's subclasses.

For each macro directive (define, undefine, visibility) have a separate object that gets chained
to the macro directive history. This has several benefits:

-No need to mutate a MacroDirective when there is a undefine/visibility directive. Stuff like
 PPMutationListener become unnecessary.
-No need to keep extra source locations for the undef/visibility locations for the define directive object
 (which is the majority of the directives)
-Much easier to hide/unhide a section in the macro directive history.
-Easier to track the effects of the directives across different submodules.

llvm-svn: 178037

Summary:
The only vector types a user can pass from MSVC code to clang code are
the ones from *mmintrin.h, so we only have to match the MSVC mangling
for these types.  MSVC mangles the __m128 family of types as tag types,
which we match.  For other vector types, we emit a unique tag type
mangling that won't match anything produced by MSVC.

Reviewers: rjmccall

CC: chandlerc, timurrrr, cfe-commits

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

llvm-svn: 178036

llvm-svn: 178035

Sam Panzer, author of loop convert, provided a list of limitations of the tool
to be documented. (Thanks Sam!)

The transform's limitations are now documented in the existing user doc.
Included are examples of the cases where the tool may change semantics.

Author: Jack Yang <jack.yang@intel.com>
llvm-svn: 178034

llvm-svn: 178033

llvm-svn: 178032

The OptimizeIntToFloatBitCast converts shift-truncate sequences
into extractelement operations.  The computation of the element
index to be used in the resulting operation is currently only
correct for little-endian targets.

This commit fixes the element index computation to be correct
for big-endian targets as well.  If the target byte order is
unknown, the optimization cannot be performed at all.

llvm-svn: 178031

llvm-svn: 178030

llvm-svn: 178029

This reverts commit r177968. It is causing failures in a local build bot.

"fatal error: error in backend: Expected a variant SchedClass"

Original commit message:
Move the CortexA9 resources into the CortexA9 SchedModel namespace. Define
resource mappings under the CortexA9 SchedModel. Define resources and mappings
for the SwiftModel.

llvm-svn: 178028

llvm-svn: 178027

llvm-svn: 178026

llvm-svn: 178025

Not only fold immediates, but avoid unnecessary copies as well.

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 178024

Prevent loading M0 multiple times.

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 178023

Just define the address as unknown instead of VReg_32.

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 178022

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 178021

They read from constant register space anyway.

v2: fix lit tests

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 178020

Just enable WQM when we see an LDS interpolation instruction.

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 178019

Restore the EXEC mask early, otherwise a copy might end up not beeing executed.

Candidate for the mesa stable branch.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 178018

If PC or SP is the destination, the disassembler erroneously failed with the
invalid encoding, despite the manual saying that both are fine.

This patch addresses failure to decode encoding T4 of LDR (A8.8.62) which is a
postindexed load, where the offset 0xc is applied to SP after the load occurs.

llvm-svn: 178017

llvm-svn: 178016

CalleeWithThisReturn can be left initialized if HasThisReturn() is false.
This change reverses the order of checks in EmitFunctionEpilog such that
CalleeWithThisReturn is only examined when it has a meaningful value.

Found with MemorySanitizer.

llvm-svn: 178015

[ASan] Change the ABI of __asan_before_dynamic_init function: now it takes pointer to private string with module name. This string serves as a unique module ID in ASan runtime. compiler-rt part

llvm-svn: 178014

[ASan] Change the ABI of __asan_before_dynamic_init function: now it takes pointer to private string with module name. This string serves as a unique module ID in ASan runtime. LLVM part

llvm-svn: 178013

llvm-svn: 178012

llvm-svn: 178011

llvm-svn: 178010

llvm-svn: 178009

There remain a number of patterns that cannot (and should not)
be handled by the asm parser, in particular all the Pseudo patterns.

This commit marks those patterns as isCodeGenOnly.

No change in generated code.

llvm-svn: 178008

MCTargetDesc/PPCMCCodeEmitter.cpp current has code like:

 if (isSVR4ABI() && is64BitMode())
   Fixups.push_back(MCFixup::Create(0, MO.getExpr(),
                                    (MCFixupKind)PPC::fixup_ppc_toc16));
 else
   Fixups.push_back(MCFixup::Create(0, MO.getExpr(),
                                    (MCFixupKind)PPC::fixup_ppc_lo16));

This is a problem for the asm parser, since it requires knowledge of
the ABI / 64-bit mode to be set up.  However, more fundamentally,
at this point we shouldn't make such distinctions anyway; in an assembler
file, it always ought to be possible to e.g. generate TOC relocations even
when the main ABI is one that doesn't use TOC.

Fortunately, this is actually completely unnecessary; that code was added
to decide whether to generate TOC relocations, but that information is in
fact already encoded in the VariantKind of the underlying symbol.

This commit therefore merges those fixup types into one, and then decides
which relocation to use based on the VariantKind.

No changes in generated code.

llvm-svn: 178007

As part of the the sequence generated to implement long double -> int
conversions, we need to perform an FADD in round-to-zero mode.  This is
problematical since the FPSCR is not at all modeled at the SelectionDAG
level, and thus there is a risk of getting floating point instructions
generated out of sequence with the instructions to modify FPSCR.

The current code handles this by somewhat "special" patterns that in part
have dummy operands, and/or duplicate existing instructions, making them
awkward to handle in the asm parser.

This commit changes this by leaving the "FADD in round-to-zero mode"
as an atomic operation on the SelectionDAG level, and only split it up into
real instructions at the MI level (via custom inserter).  Since at *this*
level the FPSCR *is* modeled (via the "RM" hard register), much of the
"special" stuff can just go away, and the resulting patterns can be used by
the asm parser.

No significant change in generated code expected.

llvm-svn: 178006

The LDrs pattern is a duplicate of LD, except that it accepts memory
addresses where the displacement is a symbolLo64.  An operand type
"memrs" is defined for just that purpose.

However, this wouldn't be necessary if the default "memrix" operand
type were to simply accept 64-bit symbolic addresses directly.
The only problem with that is that it uses "symbolLo", which is
hardcoded to 32-bit.

To fix this, this commit changes "memri" and "memrix" to use new
operand types for the memory displacement, which allow iPTR
instead of i32.  This will also make address parsing easier to
implment in the asm parser.

No change in generated code.

llvm-svn: 178005