[PowerPC] Always use "assembler dialect" 1

A setting in MCAsmInfo defines the "assembler dialect" to use.  This is used
by common code to choose between alternatives in a multi-alternative GNU
inline asm statement like the following:

  __asm__ ("{sfe|subfe} %0,%1,%2" : "=r" (out) : "r" (in1), "r" (in2));

The meaning of these dialects is platform specific, and GCC defines those
for PowerPC to use dialect 0 for old-style (POWER) mnemonics and 1 for
new-style (PowerPC) mnemonics, like in the example above.

To be compatible with inline asm used with GCC, LLVM ought to do the same.
Specifically, this means we should always use assembler dialect 1 since
old-style mnemonics really aren't supported on any current platform.

However, the current LLVM back-end uses:
  AssemblerDialect = 1;           // New-Style mnemonics.
in PPCMCAsmInfoDarwin, and
  AssemblerDialect = 0;           // Old-Style mnemonics.
in PPCLinuxMCAsmInfo.

The Linux setting really isn't correct, we should be using new-style
mnemonics everywhere.  This is changed by this commit.

Unfortunately, the setting of this variable is overloaded in the back-end
to decide whether or not we are on a Darwin target.  This is done in
PPCInstPrinter (the "SyntaxVariant" is initialized from the MCAsmInfo
AssemblerDialect setting), and also in PPCMCExpr.  Setting AssemblerDialect
to 1 for both Darwin and Linux no longer allows us to make this distinction.

Instead, this patch uses the MCSubtargetInfo passed to createPPCMCInstPrinter
to distinguish Darwin targets, and ignores the SyntaxVariant parameter.
As to PPCMCExpr, this patch adds an explicit isDarwin argument that needs
to be passed in by the caller when creating a target MCExpr.  (To do so
this patch implicitly also reverts commit 184441.)

llvm-svn: 185858

Use UsualArithmeticConversions unconditionally in analysis of
comparisons and conditional operators: the method performs
the usual arithmetic conversions if both sides are arithmetic, and
usual unary conversions if they are not.  This is just a cleanup
for conditional operators; for comparisons, it fixes the issue that
we would try to check isArithmetic() on an atomic type.

Also, fix GetExprRange() in SemaChecking.cpp so it deals with variables
of atomic type correctly.

Fixes PR15537.

llvm-svn: 185857

llvm-svn: 185856

Another bug found by llvm-stress! This fixes hitting
  llvm_unreachable("Invalid integer vector compare condition");
at the end of getVCmpInst in PPCISelDAGToDAG.

llvm-svn: 185855

llvm-svn: 185854

llvm-svn: 185853

Remove the implementation in include/llvm/Support/YAMLTraits.h.
Added a DenseMap type DITypeHashMap in DebugInfo.h:
  DenseMap<std::pair<StringRef, unsigned>, MDNode*>

llvm-svn: 185852

[ADT/NullablePtr] Allow implicit conversion of NullablePtr<OtherT> -> NullablePtr<T> if OtherT is derived from T.

llvm-svn: 185851

This reverts r185841 and relands r185831 without using
__has_attribute(const).

Clang prior to r161767 (between 3.1 and 3.2) does not accept
__has_attribute(const) due to rdar://10253857.  __const and __const__
are both keyword aliases of const, so they don't work either.

I was able to repro the buildbot failure using clang 3.1 and this patch
fixes it.  Various important versions of XCode use clang 2.9-ish, so
this workaround is necessary.

llvm-svn: 185850

llvm-svn: 185849

Update docs to say that a FunctionPass should not inspect other functions than the one being processed.
Please let me know if you disagree with this assessment (no one has yet, after asking on llvm-commits and LLVMDev) and I will revert.

llvm-svn: 185848

No functionality change. It should suffice to check the type of a debug info
metadata, instead of calling Verify.

llvm-svn: 185847

Fall back to by-element insert rather than building it up on the stack.

rdar://14351991

llvm-svn: 185846

This fixes "disassemble -m -n __printf".

llvm-svn: 185845

llvm-svn: 185844

 The symptom is seg-fault, and the root cause is that a SCEV contains a SCEVUnknown
which has null-pointer to a llvm::Value.

 This is how the problem take place:
 ===================================
  1). In the pristine input IR, there are two relevant instrutions Op1 and Op2, 
     Op1's corresponding SCEV (denoted as SCEV(op1)) is a SCEVUnknown, and
     SCEV(Op2) contains SCEV(Op1).  None of these instructions are dead.

     Op1 : V1 = ...
     ...
     Op2 : V2 = ... // directly or indirectly (data-flow) depends on Op1
    
  2) Optimizer (LSR in my case) generates an instruction holding the equivalent
     value of Op1, making Op1 dead. 
     Op1': V1' = ...
     Op1: V1 = ... ; now dead)
     Op2 : V2 = ... //Now deps on Op1', but the SCEV(Op2) still contains SCEV(Op1)

  3) Op1 is deleted, and call-back function is called to reset 
     SCEV(Op1) to indicate it is invalid. However, SCEV(Op2) is not 
     invalidated as well.

  4) Following pass get the cached, invalid SCEV(Op2), and try to manipulate it,
     and cause segfault. 

 The fix:
 ========
 It seems there is no clean yet inexpensive fix. I write to dev-list
soliciting good solution, unforunately no ack. So, I decide to fix this 
problem in a brute-force way:

  When ScalarEvolution::getSCEV is called, check if the cached SCEV 
contains a invalid SCEVUnknow, if yes, remove the cached SCEV, and
re-evaluate the SCEV from scratch.

  I compile buch of big *.c and *.cpp, fortunately, I don't see any increase
in compile time.

 Misc:
=====
 The reduced test-case has 2357 lines of code+other-stuff, too big to commit.

 rdar://14283433

llvm-svn: 185843

Since the pool indexes are necessarily sequential and contiguous, just
insert things in the right place rather than having to sort the sequence
after the fact.

No functionality change.

llvm-svn: 185842

This reverts r185831 and 185833.

llvm-svn: 185841

Another bug found by llvm-stress! This fixes crashing with:
  LLVM ERROR: Cannot select: v4f32 = frem ...

llvm-svn: 185840

Reviewed-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 185839

libclc was defining and undefing GENTYPE and several other macros with
common names in its header files.  This was preventing applications from
defining macros with identical names as command line arguments to the
compiler, because the definitions in the header files were masking the
macros defined as compiler arguements.

Reviewed-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 185838

Reviewed and Tested-by: Aaron Watry <awatry@gmail.com>

llvm-svn: 185837

Reviewed-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 185836

llvm-svn: 185835

llvm-svn: 185834

I tested r185831 by self-hosting clang with a recent clang, and got no
warnings.  I haven't been able to reproduce the problem locally.

llvm-svn: 185833

No intended functionality change.

llvm-svn: 185832

When targetting Windows, clang does not define __GNUC__, and as a result
we don't use our attributes with it.  This leads to warnings about
unused functions that are already annotated with LLVM_ATTRIBUTE_UNUSED.
Rather than testing for __clang__, we can use its __has_attribute and
__has_builtin macros directlty.

While I'm here, conditionally define and use __GNUC_PREREQ for gcc
version checks.  Spelling the check out with three comparisons is
verbose and error prone.

Reviewers: aaron.ballman

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

llvm-svn: 185831

Not intended functionality change.

llvm-svn: 185830

[PowerPC] Support time base instructions

This adds support for the old-style time base instructions;
while new programs are supposed to use mfspr, the mftb instructions
are still supported and in use by existing assembler files.

llvm-svn: 185829

This fixes llvm.org/PR16534.

Before:
aaaaa& operator+(const aaaaa&)LLVM_DELETED_FUNCTION;
After:
aaaaa& operator+(const aaaaa&) LLVM_DELETED_FUNCTION;

llvm-svn: 185828

as suggested by Takumi. To this end, added a MatchVerifier::match()
overload accepting a vector of invocation arguments.

llvm-svn: 185827

[PowerPC] Support basic compare mnemonics

This adds support for the basic mnemoics (with the L operand) for the
fixed-point compare instructions.  These are defined as aliases for the
already existing CMPW/CMPD patterns, depending on the value of L.

This requires use of InstAlias patterns with immediate literal operands.
To make this work, we need two further changes:

 - define a RegisterPrefix, because otherwise literals 0 and 1 would
   be parsed as literal register names

 - provide a PPCAsmParser::validateTargetOperandClass routine to
   recognize immediate literals (like ARM does)

llvm-svn: 185826

This fixes a regression introduced by r185726: the new call to get
a unique file does not prepend the system temporary directory, so
we need to anchor on the file that the temporary file gets moved
to to ensure we're on the same file system.

llvm-svn: 185825

In response to Duncan's review, I believe that the original comment was not as
clear as it could be. Hopefully, this is better.

llvm-svn: 185824

llvm-svn: 185823

This adds a penalty for clang-format for each break that occurs in
a set of parentheses (including fake parenthesis that determine
the range of certain operator precendences) that have not yet been
broken. Thereby, clang-format prefers similar line breaks.

This fixes llvm.org/PR15506.

Before:
const int kTrackingOptions =
    NSTrackingMouseMoved | NSTrackingMouseEnteredAndExited |
    NSTrackingActiveAlways;

After:
const int kTrackingOptions = NSTrackingMouseMoved |
                             NSTrackingMouseEnteredAndExited |
                             NSTrackingActiveAlways;

Also removed ParenState::ForFakeParenthesis which has become unused.

llvm-svn: 185822

PPCTargetLowering::LowerFP_TO_INT() expects its source operand to be
either an f32 or f64, but this is not checked.  A long double
(ppcf128) operand will normally be custom-lowered to a conversion to
f64 in this context.  However, this isn't the case for an UNDEF node.

This patch recognizes a ppcf128 as a legal source operand for
FP_TO_INT only if it's an undef, in which case it creates an undef of
the target type.

At some point we might want to do a wholesale custom lowering of
ISD::UNDEF when the type is ppcf128, but it's not really clear that's
a great idea, and probably more work than it's worth for a situation
that only arises in the case of a programming error.  At this point I
think simple is best.

The test case comes from PR16556, and is a crash-test only.

llvm-svn: 185821

Pulled out the cache clearing in the case of descendant matching, too,
for consistency, also it is not technically needed there.

FIXME: Make cache size configurable and add unit test.
llvm-svn: 185820

I shaved this yak because I mistakenly thought that this was one of the
last grep tests.  Turns out my search was skipping .ll files, for which
there are ~1200 more tests using grep.

llvm-svn: 185819