llvm-svn: 164663

scalar-to-vector conversion that we cannot handle. For instance, when an invalid
constraint is used in an inline asm statement.
<rdar://problem/12284092>

llvm-svn: 164662

llvm-svn: 164661

llvm-svn: 164660

- Instead of embedding 'lock' into each mnemonic of atomic
  instructions except 'xchg', we teach X86 assembly printer to output 'lock'
  prefix similar to or consistent with code emitter.

llvm-svn: 164659

typeid (and a couple other non-standard places where we can transform an
unevaluated expression into an evaluated expression) is special
because it introduces an an expression evaluation context,
which conflicts with the mechanism to compute the current
lambda mangling context.  PR12123.

I would appreciate if someone would double-check that we get the mangling
correct with this patch.

llvm-svn: 164658

scalar-to-vector conversion that we cannot handle. For instance, when an invalid
constraint is used in an inline asm statement.
<rdar://problem/12284092>

llvm-svn: 164657

enough information so we can mangle them correctly in cases involving
dependent parameter types. (This specifically impacts cases involving
null pointers and cases involving parameters of reference type.)
Fix the mangler to use this information instead of trying to scavenge
it out of the parameter declaration.

<rdar://problem/12296776>.

llvm-svn: 164656

for a type alias template can appear as sugar at any level of desugaring, just
like a TypedefType.

llvm-svn: 164655

Fixed issue with Release build.

llvm-svn: 164654

a crash if the path to be remaped was NULL.

<rdar://problem/12371888>

llvm-svn: 164653

The Apple buildbots are set up to pass --target to configure for both
cross- and non-cross-compile builds, and the standard autoconf response
to this is to set the program prefix to '<target>-'. Until we can figure
out the proper way to handle this (don't pass --target? pass an explicit
--program-prefix=""? don't auto-populate program_prefix with target_alias?)
it's more important to keep the buildbots running.

This reverts r164633 / ba48ceb1a3802e20e781ef04ea2573ffae2ac414.

llvm-svn: 164651

llvm-svn: 164649

llvm-svn: 164648

is_host == true so PlatformDarwin knows it can do same-host
operations like process lookup.  <rdar://problem/12296249> 

llvm-svn: 164647

llvm-svn: 164644

llvm-svn: 164643

llvm-svn: 164642

only a missed optimization opportunity if the store is over-aligned, but a
miscompile if the store's new type has a higher natural alignment than the
memcpy did. Fixes PR13920!

llvm-svn: 164641

llvm-svn: 164640

This makes the behavior clearer concerning literals with the maximum
number of digits. For a 32-bit example, 4,000,000,000 is a valid uint32_t,
but 5,000,000,000 is not, so we'd have to count 10-digit decimal numbers
as "unsafe" (meaning we have to check for overflow when parsing them,
just as we would for numbers with 11 digits or higher). This is the same,
only with 64 bits to play with.

No functionality change.

llvm-svn: 164639

rdar://12299433

llvm-svn: 164638

reason we were getting two of the same alloca is because of a memmove/memcpy
which had the same alloca in both the src and dest. Now we detect that case
directly. This has the same testcase as before, but fixes a clang test
CodeGenObjC/exceptions.m which runs clang -O2.

llvm-svn: 164636

Chandler, it's not obvious that it's okay that this alloca gets into the list
twice to begin with. Please review and see whether this is the fix you really
want, but I wanted to get a fix checked in quickly.

llvm-svn: 164634

llvm-svn: 164633

llvm-svn: 164631

llvm-svn: 164630

llvm-svn: 164629

Provide interface in TargetLowering to set or get the minimum number of basic
blocks whereby jump tables are generated for switch statements rather than an
if sequence.

    getMinimumJumpTableEntries() defaults to 4.
    setMinimumJumpTableEntries() allows target configuration.

    This patch changes the default for the Hexagon architecture to 5
    as it improves performance on some benchmarks.

llvm-svn: 164628

llvm-svn: 164627

llvm-svn: 164626

a function decl inside the ASTNodeImporter::VisitFunctionDecl function.

llvm-svn: 164625

It does a conservative estimate on the size of numbers that can fit into
uint64_t.  This bound is improved.

llvm-svn: 164624

There are very few tests here because SValBuilder is fairly aggressive
about not building SymExprs that we can't evaluate, which saves memory
and CPU but also makes it very much tied to the current constraint
manager. We should probably scale back here and let things decay to
UnknownVal later on.

bitwise-ops.c tests that for the SymExprs we do create, we persist our
assumptions about them. traversal-path-unification.c tests that we do
clean out constraints on arbitrary SymExprs once they have actually died.

llvm-svn: 164623

Previously, we'd just keep constraints around forever, which means we'd
never be able to merge paths that differed only in constraints on dead
symbols.

Because we now allow constraints on symbolic expressions, not just single
symbols, this requires changing SymExpr::symbol_iterator to include
intermediate symbol nodes in its traversal, not just the SymbolData leaf
nodes.

This depends on the previous commit to be correct. Originally applied in
r163444, reverted in r164275, now being re-applied.

llvm-svn: 164622

No tests, but this allows the optimization of removing dead constraints.
We can then add tests that we don't do this prematurely.

<rdar://problem/12333297>

Note: the added FIXME to investigate SymbolRegionValue liveness is
tracked by <rdar://problem/12368183>. This patch does not change the
existing behavior.

llvm-svn: 164621

top-level frameworks can actually be symlinked over to embedded
frameworks, and accessed via the top-level framework's headers. In
this case, we need to determine that the framework was *actually* an
embedded framework, so we can load the appropriate top-level module.

llvm-svn: 164620

llvm-svn: 164619

of this is derived from the Mach-O writer.  Reviewed by: Nick Kledzik.
 * Adds loop to SectionChunk::write traverse references calling the
   writer's fixup handler, applyFixup.
 * Adds method, ELFWriter::buildAtomToAddressMap to that creates a
   mapping from an atom to its runtime address.
 * Adds method, ELFWriter::addressOfAtom to return the runtime address
   of the atom. 

llvm-svn: 164618

doesn't transform the trivially unsafe case.

llvm-svn: 164617