If the tail-callee and caller give the same bits via the same signext/zeroext
attribute then a tail-call should be allowed, since the extension has already
been done by the callee.

llvm-svn: 188159

No functionality change.

llvm-svn: 188158

llvm-svn: 188157

Summary:
Doing work in constructors is bad: this change suggests to
call SpecialCaseList::create(Path, Error) instead of
"new SpecialCaseList(Path)". Currently the latter may crash with
report_fatal_error, which is undesirable - sometimes we want to report
the error to user gracefully - for example, if he provides an incorrect
file as an argument of Clang's -fsanitize-blacklist flag.

Reviewers: pcc

Reviewed By: pcc

CC: llvm-commits

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

llvm-svn: 188156

These functions used to assume that the lsb of an integer corresponds
to vector element 0, whereas for big-endian it's the other way around:
the msb is in the first element and the lsb is in the last element.

Fixes MultiSource/Benchmarks/mediabench/gsm/toast for z.

llvm-svn: 188155

The import name is not always the same as the symbol name. If the name/type
field in the import header is NOPREFIX or UNDECORATE, we need to strip some
characters from symbol to get its import name.

The Microsoft PE/COFF spec is vague if symbol contains more than two
consecutive characters to be stripped. We used to strip all characters,
but it doesn't seem right as we couldn't link against the system library
because of this name mangling. Looks like we shouldn't strip more than one
character.

llvm-svn: 188154

Previously these were formatting as catch (E & e) because the inner parenthesis
was being marked as an expression.

Patch by Thomas Gibson-Robinson.

llvm-svn: 188153

llvm-svn: 188152

llvm-svn: 188151

llvm-svn: 188150

is actually an instrinsic that will not occur in libc. This list here
is not exhaustive but fixes the one places in test-suite where this occurs.
I have filed a bug against myself to research the full list and add them
to the array of such cases. In the future, actual stub generation will occur
in a later phase and we won't need this code because we will know at that time
during the compilation that in fact no helper function was even needed.

llvm-svn: 188149

llvm-svn: 188148

Added a test for shuffles using VPERM.

llvm-svn: 188147

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