llvm-svn: 146420

These modifiers simply select either the low or high D subregister of a Neon
Q register.  I've also removed the unimplemented 'p' modifier, which turns out
to be a bit different than the comment here suggests and as far as I can tell
was only intended for internal use in Apple's version of gcc.

llvm-svn: 146417

llvm-svn: 146412

llvm-svn: 146411

llvm-svn: 146409

detected in the forward-CFG DFS. This prevents the reverse-CFG from
visiting blocks inside loops after blocks that dominate them in the
case where loops have multiple exits.

No testcase, because this fixes a bug which in practice only shows
up in a full optimizer run, due to the use-list order.

This fixes rdar://10422791 and others.

llvm-svn: 146408

llvm-svn: 146407

This computes the offset of the layout sucessor block, considering its
alignment as well.

llvm-svn: 146401

llvm-svn: 146400

llvm-svn: 146397

Downgrade the alignment of the initial constant island when constant
pool entries are moved elsewhere.

This is all gated by -arm-align-constant-islands.

llvm-svn: 146391

llvm-svn: 146389

 - Fixes PR11530.

llvm-svn: 146388

llvm-svn: 146385

llvm-svn: 146384

llvm-svn: 146383

Also add an MCP member pointing to the machine constant pool.

No functional change intended.

llvm-svn: 146382

llvm-svn: 146380

llvm-svn: 146379

Original commit message:
Support/FileSystem: Implement canonicalize.

llvm-svn: 146378

llvm-svn: 146377

Order constant pool entries by descending alignment in the initial
island to ensure packing and correct alignment.  When the command line
flag is set, also align the basic block containing the constant pool
entries.

This is only a partial implementation of constant island alignment. More
to come.

llvm-svn: 146375

llvm-svn: 146374

CMake versions 2.8.4 and earlier were giving this error since r146323:
"string end index: -1 is out of range 0 - 6"

Passing -1 as the length of the desired substring was a new feature
added in CMake 2.8.5:
http://www.cmake.org/Bug/view.php?id=10740

llvm-svn: 146372

I followed three heuristics for deciding whether to set 'true' or
'false':

- Everything target independent got 'true' as that is the expected
  common output of the GCC builtins.
- If the target arch only has one way of implementing this operation,
  set the flag in the way that exercises the most of codegen. For most
  architectures this is also the likely path from a GCC builtin, with
  'true' being set. It will (eventually) require lowering away that
  difference, and then lowering to the architecture's operation.
- Otherwise, set the flag differently dependending on which target
  operation should be tested.

Let me know if anyone has any issue with this pattern or would like
specific tests of another form. This should allow the x86 codegen to
just iteratively improve as I teach the backend how to differentiate
between the two forms, and everything else should remain exactly the
same.

llvm-svn: 146370

intrinsic syntax.

Now that this is explicitly covered, I plan to upgrade the existing test
suite to use an explicit immediate. Note that I plan to specify 'true'
in most places rather than the auto-upgraded value as that is the far
more common value to end up here as that is the value coming from GCC's
builtins. The only place I'm likely to put a 'false' in is when testing
x86 which actually has different instructions for the two variants.

llvm-svn: 146369

a function to upgrade. Also, simplify the code a bit at the expense of
one line.

llvm-svn: 146368

llvm-svn: 146364

llvm-svn: 146363

llvm-svn: 146362

the behavior with the newly added flag for undefined results on a zero
input.

I'm terrible at documentation, so comments and suggestions welcome here.

llvm-svn: 146361

argument of the cttz and ctlz intrinsics.

llvm-svn: 146360

indicates whether the intrinsic has a defined result for a first
argument equal to zero. This will eventually allow these intrinsics to
accurately model the semantics of GCC's __builtin_ctz and __builtin_clz
and the X86 instructions (prior to AVX) which implement them.

This patch merely sets the stage by extending the signature of these
intrinsics and establishing auto-upgrade logic so that the old spelling
still works both in IR and in bitcode. The upgrade logic preserves the
existing (inefficient) semantics. This patch should not change any
behavior. CodeGen isn't updated because it can use the existing
semantics regardless of the flag's value.

Note that this will be followed by API updates to Clang and DragonEgg.

Reviewed by Nick Lewycky!

llvm-svn: 146357

Accidentally left out since r145214/r145217.

llvm-svn: 146356

The OptLevel is now redundant with the TargetMachine*.
And selectTarget() isn't really JIT-specific and could probably
get refactored into one of the lower level libraries.

llvm-svn: 146355

Remove some remants of the old palign pattern fragment that were still hanging around. Also remove a cast from inside getShuffleVPERM2X128Immediate and getShuffleVPERMILPImmediate since the only caller already had done the cast.

llvm-svn: 146344

Fixed bug 9905: Failure in code selection for llvm intrinsics sqrt/exp (fix for FSQRT, FSIN, FCOS, FPOWI, FPOW, FLOG, FLOG2, FLOG10, FEXP, FEXP2). Third attempt: simplified checks in test for armv7-apple-darwin11.

llvm-svn: 146341

llvm-svn: 146340

llvm/CMakeLists.txt: Fix LLVM_LIT_TOOLS_DIR since r143728. Cygwin does not need optional tools dir. MSVC and mingw may need one.

llvm-svn: 146339

of r146334!

llvm-svn: 146338