SROA-based analysis has enough information. This should work now that
both mem2reg *and* the SSAUpdater-based AllocaPromoter have been updated
to be able to promote the types of allocas that the SROA analysis
detects.

I've included tests for the AllocaPromoter that were only possible to
write once we fast-tracked promotable allocas without rewriting them.
This includes a test both for r187347 and r188145.

Original commit log for r187323:
"""
Now that mem2reg understands how to cope with a slightly wider set of uses of
an alloca, we can pre-compute promotability while analyzing an alloca for
splitting in SROA. That lets us short-circuit the common case of a bunch of
trivially promotable allocas. This cuts 20% to 30% off the run time of SROA for
typical frontend-generated IR sequneces I'm seeing. It gets the new SROA to
within 20% of ScalarRepl for such code. My current benchmark for these numbers
is PR15412, but it fits the general pattern of IR emitted by Clang so it should
be widely applicable.
"""

llvm-svn: 188146

the more general set of patterns that are now handled by mem2reg and that we
can detect quickly while doing SROA's initial analysis. Notably, this allows it
to promote through no-op bitcast and GEP sequences. A core part of the
SSAUpdater approach is the ability to test whether a particular instruction is
part of the set being promoted. Testing this becomes significantly more complex
in the world where the operand to every load and store isn't the alloca itself.
I ended up using the approach of walking up the def-chain until we find the
alloca. I benchmarked this against keeping a set of pointer operands and
keeping a set of the loads and stores we care about, and this one seemed faster
although the difference was very small.

No test case yet because currently the rewriting always "fixes" the inputs to
not require this. The next patch which re-enables early promotion of easy cases
in SROA will include a test case that specifically exercises this aspect of the
alloca promoter.

llvm-svn: 188145

our visiting datastructures in the AllocaPromoter/SSAUpdater path of
SROA. Also shift the order if clears around to be more consistent.

No functionality changed here, this is just a cleanup.

llvm-svn: 188144

instruction move. Just affects static relocation. -static works fine now
with mips16 for the most part.

llvm-svn: 188143

It is breaking builbots with libgmalloc enabled on Mac OS X.

$ cd llvm ; mkdir release ; cd release
$ ../configure --enable-optimized —prefix=$PWD/install
$ make
$ make check
$ Release+Asserts/bin/llvm-lit -v --param use_gmalloc=1 --param \
  gmalloc_path=/usr/lib/libgmalloc.dylib \
  ../test/Instrumentation/DataFlowSanitizer/args-unreachable-bb.ll

llvm-svn: 188142

llvm-svn: 188141

llvm-svn: 188140

Omit  llvm:: before StringRef and SmallString. We have using directive in include/clang/Basic/LLVM.h.

llvm-svn: 188139

Omit  llvm:: before SmallVector and SmallVectorImpl. We have using directive in include/clang/Basic/LLVM.h.

llvm-svn: 188138

Fix to PR16225 (Assert-on-invalid: isa<LabelDecl>(D) && "declaration not instantiated in this scope")

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

llvm-svn: 188137

llvm-svn: 188136

llvm-svn: 188135

llvm-svn: 188134

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

llvm-svn: 188133

llvm-svn: 188132

llvm-svn: 188131

llvm-svn: 188130

llvm-svn: 188129

llvm-svn: 188128

- va_list checker (PR16811 and PR16812)
- Model floating-point values
- Bound bitwise masking operations (PR16615)
- Bound C string length (PR16558 and others)

llvm-svn: 188127

llvm-svn: 188126

Some users (clang, libTooling) require this. After this patch we can remove
the calls to getenv("PWD") from clang.

llvm-svn: 188125

Fixed a case where GCC was emitting a DW_TAG_class_type that has a DW_AT_declaration set to true, yet the class actually contains a definition for the class in that DIE.

llvm-svn: 188124

CXXPseudoDestructorExprs may not contain a type.  PR16852.

llvm-svn: 188123

[objc-arc] Track if we encountered an additive overflow while computing {TopDown,BottomUp}PathCounts and do nothing if it occurred.

I fixed the aforementioned problems that came up on some of the linux boxes.
Major thanks to Nick Lewycky for his help debugging!

rdar://14590914

llvm-svn: 188122

Summary:
Source-centric tools need access to the location of a C++11
lambda expression's capture-default ('&' or '=') when it's present.
It's possible for them to find it by re-lexing and re-implementing
rules that Clang's parser has already applied, but the cost of storing
the SourceLocation and making it available to them is 32 bits per
LambdaExpr (a small delta, proportionally), and the simplification in
client code is significant.

Reviewers: rsmith

Reviewed By: rsmith

CC: cfe-commits, klimek, revane

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

llvm-svn: 188121

llvm-svn: 188120

This moves removeUnreachableBlocksFromFn from SimplifyCFGPass.cpp
to Utils/Local.cpp and uses it to replace the implementation of
llvm::removeUnreachableBlocks, which appears to do a strict subset
of what removeUnreachableBlocksFromFn does.

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

llvm-svn: 188119

llvm-svn: 188117

llvm-svn: 188116

llvm-svn: 188114

under the args ABI.

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

llvm-svn: 188113

comparing non-reference function parameters.  The qualifiers don't matter for
comparisons.

This is a re-commit of r187769, which was accidentially reverted in r187770,
with a simplification at the suggestion of Eli Friedman.

llvm-svn: 188112

 - The actual tests have better coverage than those, and they weren't useful
   anymore.

llvm-svn: 188110

llvm-svn: 188109

llvm-svn: 188108

llvm-svn: 188107

I need to go through all the runtime routine list and see if there
are any more I need to add for mips16 floating point. Prototypes must
be correct or else I don't know to add a helper function call.

llvm-svn: 188106

[stackprotector] Simplify SP Pass so that we emit different fail basic blocks for each fail condition.

This patch decouples the stack protector pass so that we can support stack
protector implementations that do not use the IR level generated stack protector
fail basic block.

No codesize increase is caused by this change since the MI level tail merge pass
properly merges together the fail condition blocks (see the updated test).

llvm-svn: 188105

llvm-svn: 188103