Merge clang 3.3 release and various fixes: r241214, r246705, r248548,

Merge clang 3.3 release and various fixes: r241214, r246705, r248548,
r249423, r249817, r250217, r250593, r250616, r250997, r251216, r251662,
r251761, r251785, r251790, r252039.

MFC r241214 (by jkim):
  Do not install incomplete unwind.h from clang.  This header file was meant
  to be a wrapper for the canonical system header file.  Unfortunately, we do
  not have one (yet) and some times it is causing weird failures when clang
  is used for building ports.  More complete and correct file will come from
  libcxxrt in the future.

  Discussed with:	dim, kib, theraven

MFC r246705 (by andrew):
  Allow us to build clang for ARM EABI. Clang and llvm use the
  arm-gnueabi-freebsd10.0 triple for EABI. Use this when we are on arm or
  armv6 and are building for EABI.

  Reviewed by:	dim

MFC r248548 (by andrew):
  Pull in r177252 from upstream clang trunk:

   Make sure to use same EABI version for external assembler as for
   integrated as.

  This allows us to use gcc on a world built with clang on ARM.

MFC r249423:
  Upgrade our copy of llvm/clang to trunk r178860, in preparation of the
  upcoming 3.3 release (branching and freezing expected in a few weeks).

  Preliminary release notes can be found at the usual location:
  <http://llvm.org/docs/ReleaseNotes.html>

  An MFC is planned once the actual 3.3 release is finished.

MFC r249817:
  Pull in r180121 from upstream llvm trunk:

    LoopVectorizer: Fix 15830. When scalarizing and unrolling stores make
    sure that the order in which the elements are scalarized is the same
    as the original order.
    This fixes a miscompilation in FreeBSD's regex library.

  This should fix lib/libc/regex/regcomp.c at -O3 with clang 3.3 r178860
  on CPUs with SSE.  Before this change, the vectorizer could incorrectly
  rearrange the second loop in computejumps(), leading to possibly invalid
  entries in the re_gets::charjump table.

  The net result was that for example "sed s/@CC@/foo/" failed to work
  correctly, leading to trouble with many configure scripts.

MFC r250217:
  Allow building clang on older FreeBSD releases, where log2() does not
  exist yet.  With this change, I have verified that building head on
  8.1-RELEASE works.

  Noticed by:	Ryan Stone <rysto32@gmail.com>

MFC r250593:
  Pull in r181286 from upstream llvm trunk:

    LoopVectorize: getConsecutiveVector must respect signed arithmetic

    We were passing an i32 to ConstantInt::get where an i64 was needed and we must
    also pass the sign if we pass negatives numbers. The start index passed to
    getConsecutiveVector must also be signed.

    Should fix PR15882.

  This should fix Firefox crashes some people have been reporting, when it
  is compiled with -O3.

MFC r250616:
  Use an ugly hack to get around bootstrapping problems when building
  clang on head between r239347 and r245428.

  The former revision introduced CLOCK_PROCESS_CPUTIME_ID as a clock id
  for the clock_gettime() function and friends, but it was only added in
  <sys/time.h>, not in <time.h>.  Any program including <time.h> would
  therefore not be able to use CLOCK_PROCESS_CPUTIME_ID, even though the
  value of _POSIX_CPUTIME indicates its existence.  The latter revision
  synchronized the defines again.

  Work around this problem by defining the id on the command line for the
  particular .cpp file that needs it.  If the id ever changes value, this
  hack will need to be updated.

MFC r250997:
  Pull in r182656 from upstream llvm trunk:

    LoopVectorize: LoopSimplify can't canonicalize loops with an
    indirectbr in it, don't assert on those cases.

    Fixes PR16139.

  This should fix clang assertion failures when optimizing at -O3, similar
  to:

    Assertion failed: (TheLoop->getLoopPreheader() && "No preheader!!"),
    function canVectorize, file
    contrib/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp, line 2171.

  Reported by:	O. Hartmann <ohartman@zedat.fu-berlin.de>
  PR:		ports/178332, ports/178977

MFC r251216 (by ed):
  Pull in r183033 and r183036 from LLVM trunk:

    Add support for optimized (non-generic) atomic libcalls.

    For integer types of sizes 1, 2, 4 and 8, libcompiler-rt (and libgcc)
    provide atomic functions that pass parameters by value and return
    results directly.

    libgcc and libcompiler-rt only provide optimized libcalls for
    __atomic_fetch_*, as generic libcalls on non-integer types would make
    little sense. This means that we can finally make __atomic_fetch_*
    work
    on architectures for which we don't provide these operations as
    builtins
    (e.g. ARM).

    This should fix the dreaded "cannot compile this atomic library call
    yet" error that would pop up once every while.

  This should make it possible for me to get C11 atomics working on all of
  our platforms.

MFC r251662:
  Upgrade our copy of llvm/clang to 3.3 release.

  Release notes are still in the works, these will follow soon.

MFC r251761:
  Pull in r181620 from llvm trunk:

    [ms-inline asm] Fix a crasher when we fail on a direct match.

    The issue was that the MatchingInlineAsm and VariantID args to the
    MatchInstructionImpl function weren't being set properly.  Specifically, when
    parsing intel syntax, the parser thought it was parsing inline assembly in the
    at&t dialect; that will never be the case.

    The crash was caused when the emitter tried to emit the instruction, but the
    operands weren't set.  When parsing inline assembly we only set the opcode, not
    the operands, which is used to lookup the instruction descriptor.
    rdar://13854391 and PR15945

    Also, this commit reverts r176036.  Now that we're correctly parsing the intel
    syntax the pushad/popad don't match properly.  I've reimplemented that fix using
    a MnemonicAlias.

  Pull in r183907 from llvm trunk:

    X86: Make the cmov aliases work with intel syntax too.

  These commits make a number of Intel-style inline assembly mnemonics
  aliases (occurring in several ports) work properly, which could cause
  assertions otherwise.

  Reported by:	kwm, bapt

MFC r251785 (by ed)
  Pull in r184040 from upstream clang trunk:

    Emit native implementations of atomic operations on FreeBSD/armv6.

    Just like on Linux, FreeBSD/armv6 assumes the system supports
    ldrex/strex unconditionally. It is also used by the kernel. We can
    therefore enable support for it, like we do on Linux.

    While there, change one of the unit tests to explicitly test against
    armv5 instead of armv7, as it actually tests whether libcalls are
    emitted.

MFC r251790 (by andrew):
  Pull in r183926 from LLVM trunk:

    Allow clang to build __clear_cache on ARM.

    __clear_cache is special. It needs no signature, but is a real function in
    compiler_rt or libgcc.

    Patch by Andrew Turner.

  This allows us to build the __clear_cache function in compiler-rt.

MFC r252039:
  Pull in r183984 from llvm trunk:

    Make PrologEpilogInserter save/restore all callee saved registers in
    functions which call __builtin_unwind_init()

    __builtin_unwind_init() is an undocumented gcc intrinsic which has
    this effect, and is used in libgcc_eh.

    Goes part of the way toward fixing PR8541.

  This obsoletes the ugly hack to libgcc's unwind code from r245272, and
  should also work for other arches, so revert the hack too.

git-svn-id: svn://svn.freebsd.org/base/stable/9@252723 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f