llvm-svn: 155696

rdar://problem/11327790

llvm-svn: 155694

Use a deque instead of an ImmutableList in AnalysisConsumer to preserve the file order that functions are visited.  Should fix the buildbots.

llvm-svn: 155693

llvm-svn: 155692

llvm-svn: 155691

llvm-svn: 155690

llvm-svn: 155689

llvm-svn: 155687

llvm-svn: 155686

  instructions.
- However, it does support dmb, dsb, isb, mrs, and msr.
rdar://11331541

llvm-svn: 155685

Clean up the way modules are looked for when calling Target::GetSharedModule(...). We were ignoring remapped files, even if they were valid. Also if we have a  UUID, we should check our global module list first.

llvm-svn: 155683

instead of getAggregateElement. This has the advantage of being
more consistent and allowing higher-level constant folding to
procede even if an inner extract element cannot be folded.

Make ConstantFoldInstruction call ConstantFoldConstantExpression
on the instruction's operands, making it more consistent with 
ConstantFoldConstantExpression itself. This makes sure that
ConstantExprs get TargetData-aware folding before being handed
off as operands for further folding.

This causes more expressions to be folded, but due to a known
shortcoming in constant folding, this currently has the side effect
of stripping a few more nuw and inbounds flags in the non-targetdata
side of constant-fold-gep.ll. This is mostly harmless.

This fixes rdar://11324230.

llvm-svn: 155682

llvm-svn: 155681

of a mutable SmallPtrSet.  While iterating over LocalTUDecls, there were cases
where we could modify LocalTUDecls, which could result in invalidating an iterator
and an analyzer crash.  Along the way, switch some uses of std::queue to std::dequeue,
which should be slightly more efficient.

Unfortunately, this is a difficult case to create a test case for.

llvm-svn: 155680

llvm-svn: 155679

llvm-svn: 155678

to a given type, when the reason is that there is a non-type decl with
the same name.

llvm-svn: 155677

The required checks are moved to ChainInstruction() itself and the
policy decisions are moved to IVChain::isProfitableInc().

Also cache the ExprBase in IVChain to avoid frequent recomputations.

No functional change intended.

llvm-svn: 155676

No functional change intended.

llvm-svn: 155675

 (x & y) | (x ^ y) -> x | y 
 (x & y) + (x ^ y) -> x | y 

Patch by Manman Ren.
rdar://10770603

llvm-svn: 155674

of writing a __block variable being initialized with
a constructed object. // rdar://11326988

llvm-svn: 155673

llvm-svn: 155670

llvm-svn: 155669

DAGCombine strangeness may result in multiple loads from the same
offset. They both may try to glue themselves to another load. We could
insist that the redundant loads glue themselves to each other, but the
beter fix is to bail out from bad gluing at the time we detect it.

Fixes rdar://11314175: BuildSchedUnits assert.

llvm-svn: 155668

llvm-svn: 155667

Add a test for PR12674.

llvm-svn: 155666

Don't call SBDebugger::SetInternalVariable in the sigwinch_handler, since that takes locks and potentially does allocations.
Just call SBDebugger::SetTerminalWidth on the driver's SBDebugger, which does the same job, but no locks.
Also add the value checking to SetTerminalWidth you get with SetInternalVariable(..., "term-width", ...).

rdar://problem/11310563

llvm-svn: 155665

// rdar://11323676

llvm-svn: 155664

where getter type is super class of its property 
type, resulting in an assert. // rdar://11323676

llvm-svn: 155663

more aligned than the block header but also contains something
smaller than the block-header alignment but not exactly half
the difference between the large alignment and the header
alignment.  Got that?

I'm really not sure what I was thinking with the buggy computation
here, but the fix is pretty obvious.

llvm-svn: 155662

llvm-svn: 155661

ones, to its own constant pool.  This reflects the fact
that the LLVM code generators for different targets move
floats to their constant pools under varying conditions,
and the JIT cannot (yet) be relied upon to relocate references to
its constant pool correctly.

llvm-svn: 155660

The base address for the PC-relative load is Align(PC,4), so it's the
address of the word containing the 16-bit instruction, not the address
of the instruction itself. Ugh.

rdar://11314619

llvm-svn: 155659

Patch by Yang Chen.

llvm-svn: 155658

llvm-svn: 155657

llvm-svn: 155656

Trivial change to set UseLeaForSP flag in addition to toggling
the FeatureLeaForSP feature bit when llvm auto detects Intel Atom.

Patch by Andy Zhang

llvm-svn: 155655

While making lld build under the tools directory I decided to refactor how this
works.

There is now a macro, add_llvm_external_project, which takes the name of the
expected subdirectory. This sets up two CMake options.

 * LLVM_EXTERNAL_${NAME}_SOURCE_DIR
     This is the path to the source. It defaults to
     ${CMAKE_CURRENT_SOURCE_DIR}/${name}.
 * LLVM_EXTERNAL_${NAME}_BUILD
     Enable and disable building the tool as part of LLVM.

I chose LLVM_EXTERNAL_${NAME} as a prefix so they all show up together in the
GUI.

llvm-svn: 155654

'REPLACEMENT CHARACTER' (U+FFFD) when getAsInteger fails.

llvm-svn: 155653

llvm-svn: 155652