PPC: Mark vector FREM as Expand by default

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185840 91177308-0d34-0410-b5e6-96231b3b80d8
Revert: "Use Clang's __has_* macros in Compiler.h to test for features"

This reverts r185831 and 185833.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185841 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Simplify Address Pool index handling.

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185842 91177308-0d34-0410-b5e6-96231b3b80d8
 Fix a SCEV update problem.

 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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185843 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Correct comment & re-format a nearby loop

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185844 91177308-0d34-0410-b5e6-96231b3b80d8
ARM: Improve codegen for generic vselect.

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

rdar://14351991

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185846 91177308-0d34-0410-b5e6-96231b3b80d8
Debug Info: clean up usage of Verify.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185847 91177308-0d34-0410-b5e6-96231b3b80d8
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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185848 91177308-0d34-0410-b5e6-96231b3b80d8
Reland "Use Clang's __has_* macros in Compiler.h ..." with fixes

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185850 91177308-0d34-0410-b5e6-96231b3b80d8
[ADT/NullablePtr] Allow implicit conversion of NullablePtr<OtherT> -> NullablePtr<T> if OtherT is derived from T.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185851 91177308-0d34-0410-b5e6-96231b3b80d8
StringRef: add DenseMapInfo for StringRef.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185852 91177308-0d34-0410-b5e6-96231b3b80d8
Add a comment to this change, requested by Eric Christopher.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185853 91177308-0d34-0410-b5e6-96231b3b80d8
IR headers moved to llvm/IR some aeons ago, update documentation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185854 91177308-0d34-0410-b5e6-96231b3b80d8
PPC: Mark vector CC action for SETO and SETONE as Expand

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

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

[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.)



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185858 91177308-0d34-0410-b5e6-96231b3b80d8
Allow llvm_find_program to find alternate names

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185859 91177308-0d34-0410-b5e6-96231b3b80d8
Find xdot or xdot.py.

Ubuntu installs this as xdot, so finding xdot.py would fail.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185861 91177308-0d34-0410-b5e6-96231b3b80d8
Update comment to avoid mentioning DbgValues which is an instance
variable later in the class.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185866 91177308-0d34-0410-b5e6-96231b3b80d8
No ',' between programs.

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