llvm-svn: 206741

No functionality change.

llvm-svn: 206740

teach the opt driver to use it rather than a manual list.

llvm-svn: 206739

Generating BZHI in the variable mask case, i.e. (and X, (sub (shl 1, N), 1)),
was already supported, but we were missing the constant-mask case. This patch
fixes that.

<rdar://problem/15480077>

llvm-svn: 206738

file. This will make it easy to scale up the number of passes supported.
Currently, it just supports the function and module transformation
passes that were already supported in the opt tool explicitly.

llvm-svn: 206737

llvm-svn: 206736

Original commit message:
  Implement builtins for safe division: safe.sdiv.iN, safe.udiv.iN,
  safe.srem.iN, safe.urem.iN (iN = i8, i61, i32, or i64).

llvm-svn: 206735

llvm-svn: 206734

llvm-svn: 206733

safe.urem.iN (iN = i8, i16, i32, or i64).

llvm-svn: 206732

The lldb-gdbserver tests are skipped if the lldb-gdbserver exe cannot be found (currently only built for Linux and FreeBSD).  The lldb-gdbserver exe is found by the LLDB_EXEC environment variable, using the same dir as the lldb exe, and then replacing lldb with lldb-gdbserver.

llvm-svn: 206731

llvm-svn: 206730

Unlike the standard AAPCS64 ABI, variadic arguments are always passed on the
stack with the Darwin ABI, and this was not being considered when deciding
whether to expand HFA/HVA arguments in a call. An HFA argument with a "float"
base type was being expanded into separate "float" arguments, each of which
was then extended to a double, resulting in a serious mismatch from what is
expected by the va_arg implementation. <rdar://problem/15777067>

llvm-svn: 206729

llvm-svn: 206728

It could even be made non-virtual if it weren't for bad compiler
warnings.

This demonstrates that ArgList objects aren't destroyed polymorphically
and possibly that they aren't even used polymorphically. If that's the
case, it might be possible to refactor the two ArgList types more
separately and simplify the Arg ownership model. *continues
experimenting*

llvm-svn: 206727

llvm-svn: 206726

llvm-svn: 206725

This might be able to be simplified further by using Arg as a value type
in a linked list (to maintain pointer validity), but here's something
simple to start with.

llvm-svn: 206724

llvm-svn: 206723

llvm-svn: 206722

llvm-svn: 206721

Don't provide two different definitions of ModRMDecision, OpcodeDecision, and ContextDecision in different source files (depending on #define magic).

llvm-svn: 206720

different source files.

llvm-svn: 206719

llvm-svn: 206718

reason to expose a global symbol 'decodeInstruction' nor to pollute the global
scope with a bunch of external linkage entities (some of which conflict with
others elsewhere in LLVM).

This is just the initial transition to C++; more cleanups to follow.

llvm-svn: 206717

table entry for MIPS.

llvm-svn: 206716

llvm-svn: 206715

entirely clear whether this should be valid with modules enabled, but the fixed
code is cleaner regardless.

Also fix a TU-local type that accidentally had external linkage.

llvm-svn: 206714

Patch by Robert Matusewicz

llvm-svn: 206713

Implement Diagnostic::category_name() using clang_getDiagnosticCategoryText()
instead of the deprected clang_getDiagnosticCategoryName().

Preserves existing behaviour and API covered by existing tests.

llvm-svn: 206712

Patch by Robert Matusewicz

llvm-svn: 206711

Cleanup only.

llvm-svn: 206710

Cleanup only.

llvm-svn: 206709

Spotted by Nick Lewycky in review, thanks!

llvm-svn: 206708

This reverts commit r206704, as expected.

llvm-svn: 206707

This reverts commit r206705, as planned.

llvm-svn: 206706

These tests fail after my BlockFrequencyInfo rewrite on two buildbots
[1][2].  I can't reproduce it locally, so I'm temporarily turning on
-debug-only=block-freq so I can find the problem.

[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1860
[2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18477

llvm-svn: 206705

This reverts commit r206677, reapplying my BlockFrequencyInfo rewrite.

I've done a careful audit, added some asserts, and fixed a couple of
bugs (unfortunately, they were in unlikely code paths).  There's a small
chance that this will appease the failing bots [1][2].  (If so, great!)

If not, I have a follow-up commit ready that will temporarily add
-debug-only=block-freq to the two failing tests, allowing me to compare
the code path between what the failing bots and what my machines (and
the rest of the bots) are doing.  Once I've triggered those builds, I'll
revert both commits so the bots go green again.

[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816
[2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18445

<rdar://problem/14292693>

llvm-svn: 206704

This test didn't work as intended and was ultimately disabled some years ago in
r169458.

Indeed it's not clear if the '\n' was ever passed through to the driver
correctly given that lit would insert '&& {' at the newline.

Test rewritten to use printf/xargs to insert '\n' in a more reliable manner and
to use FileCheck for verification.

llvm-svn: 206703

When compiling on Linux with GCC 4.8, compilation would fail due to the use of
the offsetof macro.  This is a standard macro, defined in stddef.h.  Include
this header to ensure that offsetof is declared.

llvm-svn: 206702