llvm-svn: 146379

Original commit message:
Support/FileSystem: Implement canonicalize.

llvm-svn: 146378

llvm-svn: 146377

As an extension, support incomplete types in the unordered containers to match what we already do in the associative containers.

llvm-svn: 146376

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

llvm-svn: 146373

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

llvm-svn: 146371

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: 146367

did not!

llvm-svn: 146366

diagnostics. No functionality change.

llvm-svn: 146365

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

setting the is_zero_undef flag appropriately to true as that matches the
semantics of these GCC builtins.

This is the Clang side of r146357 in LLVM.

llvm-svn: 146358

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

llvm-svn: 146354

llvm-svn: 146345

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

[analyzer] CStringChecker should not rely on the analyzer generating UndefOrUnknown value when it cannot reason about the expression.

We are now often generating expressions even if the solver is not known to be able to simplify it. This is another cleanup of the existing code, where the rest of the analyzer and checkers should not base their logic on knowing ahead of the time what the solver can reason about. 

In this case, CStringChecker is performing a check for overflow of 'left+right' operation. The overflow can be checked with either 'maxVal-left' or 'maxVal-right'. Previously, the decision was based on whether the expresion evaluated to undef or not. With this patch, we check if one of the arguments is a constant, in which case we know that 'maxVal-const' is easily simplified. (Another option is to use canReasonAbout() method of the solver here, however, it's currently is protected.)

This patch also contains 2 small bug fixes:
 - swap the order of operators inside SValBuilder::makeGenericVal.
 - handle a case when AddeVal is unknown in GenericTaintChecker::getPointedToSymbol.

llvm-svn: 146343

Silences valgrind warnings about uninitalized alignment values.

llvm-svn: 146342

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

Forgot to commit the Header files. 
Rename generateUnknownVal -> makeGenericVal.

llvm-svn: 146337

Fix a bug in SimpleSValBuilder, where we should swap lhs and rhs when calling generateUnknownVal(), - the function which creates symbolic expressions when data is tainted. The issue is not visible when we only create the expressions for taint since all expressions are commutative from taint perspective.

Refactor SymExpr::symbol_iterator::expand() to use a switch instead of a chain of ifs.

llvm-svn: 146336

llvm-svn: 146335

the only parts of TM that depends on CodeGen headers with it.

llvm-svn: 146334

such as what VCS information is attached.

llvm-svn: 146333

llvm-svn: 146332

[fast-isel] SelectInsertValue seems to be causing miscompiles for ARM.  Disable while I investigate.

llvm-svn: 146331