In the ARM back-end, build_vector nodes are lowered to a target specific
build_vector that uses floating point type. 
This works well, unless the inserted bitcasts survive until instruction
selection. In that case, they incur moves between integer unit and floating
point unit that may result in inefficient code.

In other words, this conversion may introduce artificial dependencies when the
code leading to the build vector cannot be completed with a floating point type.

In particular, this happens when loads are not aligned.

Before this patch, in that case, the compiler generates general purpose loads
and creates the floating point vector from them, instead of directly using the
vector unit.

The patch uses a vector friendly sequence of code when the inserted bitcasts to
floating point survived DAGCombine.

This is done by a target specific DAGCombine that changes the target specific
build_vector into a sequence of insert_vector_elt that get rid of the bitcasts.

<rdar://problem/14170854>

llvm-svn: 185587

llvm-svn: 185586

(and for consistency).

llvm-svn: 185585

llvm-svn: 185584

Long double is 64 bits on FreeBSD PPC, so the f128 entry is superfluous.

llvm-svn: 185583

Long double is 64 bits on FreeBSD PPC, so the f128 entry is superfluous.

llvm-svn: 185582

llvm-svn: 185581

PR16456 reported that Clang implements a hybrid between AltiVec's
"Keyword and Predefine Method" and its "Context Sensitive Keyword
Method," where "bool" is always a keyword, but "vector" and "pixel"
are context-sensitive keywords.  This isn't permitted by the AltiVec
spec.  For consistency with gcc, this patch implements the Context
Sensitive Keyword Method for bool, and stops treating true and false
as keywords in Altivec mode.

The patch removes KEYALTIVEC as a trigger for defining these keywords
in include/clang/Basic/TokenKinds.def, and adds logic for "vector
bool" that mirrors the existing logic for "vector pixel."  The test
case is taken from the bug report.

llvm-svn: 185580

Remove @expectedFailureGcc from TestInlineStepping as function prologue bug is not reproducible anymore.

llvm-svn: 185579

llvm-svn: 185578

llvm-svn: 185577

- should resolve remaining failures on clang buildbot

llvm-svn: 185576

ARM: Prevent ARMAsmParser::shouldOmitCCOutOperand() from misidentifying certain Thumb2 add immediate T3 encodings.

Before the fix Thumb2 instructions of type "add rD, rN, #imm" (T3 encoding, see ARM ARM A8.8.4) with rD and rN both being low registers (r0-r7) were classified as having the T4 encoding.

The T4 encoding doesn't have a cc_out operand so for above instructions the operand gets erroneously removed, corrupting the token stream and leading to parse errors later in the process.

This bug prevented "add r1, r7, #0xcbcbcbcb" from being assembled correctly.

Fixes <rdar://problem/14224440>.

llvm-svn: 185575

llvm-svn: 185574

llvm-svn: 185573

It's not the case on ie. FreeBSD.

llvm-svn: 185572

- this issue was detected on recent GCC buildbot runs

llvm-svn: 185571

llvm-svn: 185570

llvm-svn: 185569

Without fmath-errno, Clang currently generates calls to @llvm.pow.* intrinsics
when it sees pow*(). This may not be suitable for all targets (for
example le32/PNaCl), so the attached patch adds a target hook that CodeGen
queries. The target can state its preference for having or not having the
intrinsic generated. Non-PNaCl behavior remains unchanged;
PNaCl-specific test added.

llvm-svn: 185568

- argparse_compat library does not support reading environment variables
- should unblock Linux GCC buildbot from running tests again

llvm-svn: 185567

Patch by Alex Crichton <alex@crichton.co>.  Approved by Chris Lattner.

llvm-svn: 185566

<stdint.h> (which might not exist or might not work).

llvm-svn: 185565

[PowerPC] Support lmw/stmw in the asm parser

This adds support for the load/store multiple instructions,
currently used by the asm parser only.

llvm-svn: 185564

Verify that assembling an empty file does not auto-include altivec.h.

llvm-svn: 185563

Fixes crash when trying to recover from a crash on an assembler-with-cpp
file.  (Not sure how to write a testcase.)

llvm-svn: 185562

[PowerPC] Use mtocrf when available

Just as with mfocrf, it is also preferable to use mtocrf instead of
mtcrf when only a single CR register is to be written.

Current code however always emits mtcrf.  This probably does not matter
when using an external assembler, since the GNU assembler will in fact
automatically replace mtcrf with mtocrf when possible.  It does create
inefficient code with the integrated assembler, however.

To fix this, this patch adds MTOCRF/MTOCRF8 instruction patterns and
uses those instead of MTCRF/MTCRF8 everything.  Just as done in the
MFOCRF patch committed as 185556, these patterns will be converted
back to MTCRF if MTOCRF is not available on the machine.

As a side effect, this allows to modify the MTCRF pattern to accept
the full range of mask operands for the benefit of the asm parser.

llvm-svn: 185561

- build fails due to PyCallable template definition inside an extern "C" scope

This commit reverts 185240, 184893 and 184608.

llvm-svn: 185560

llvm-svn: 185559

x86/x86-64 clang optimizes to direct word accesses anyway.  This fixes an unaligned word access in murmurhash/cityhash.

llvm-svn: 185558

llvm-svn: 185557

[PowerPC] Always use mfocrf if available

When accessing just a single CR register, it is always preferable to
use mfocrf instead of mfcr, if the former is available on the CPU.

Current code makes that distinction in many, but not all places
where a single CR register value is retrieved.  One missing
location is PPCRegisterInfo::lowerCRSpilling.

To fix this and make this simpler in the future, this patch changes
the bulk of the back-end to always assume mfocrf is available and
simply generate it when needed.

On machines that actually do not support mfocrf, the instruction
is replaced by mfcr at the very end, in EmitInstruction.

This has the additional benefit that we no longer need the
MFCRpseud hack, since before EmitInstruction we always have
a MFOCRF instruction pattern, which already models data flow
as required.

The patch also adds the MFOCRF8 version of the instruction,
which was missing so far.

Except for the PPCRegisterInfo::lowerCRSpilling case, no change
in generated code intended.

llvm-svn: 185556

This is important for preprocessing steps, which may output to stdout.

Also, change ENV accesses using barewords to use string keys instead.

PR16414

llvm-svn: 185555

llvm-svn: 185554

Symbol prologue code checks if funciton lines up with symbol and uses function prologue code with line info if so.

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

llvm-svn: 185553

It was only passing because 'grep andpd' was not finding any andpd, but
we don't fail if part of a pipe fails.

llvm-svn: 185552

llvm-svn: 185551

llvm-svn: 185550

llvm-svn: 185549

Previously, the CMake build still tried to link clang against the static
analyzer libraries, even if CLANG_ENABLE_STATIC_ANALYZER was off.
Furthermore, clang-check depends on the analyzer, so it should be disabled
(in both CMake and configure builds).

In theory, clang-check could be made to conditionally include analyzer
support (like clang itself), but for now this at least gets a CMake ALL_BUILD
working.

Patch by Stephen Kelly, modified by me.

llvm-svn: 185548