available.

llvm-svn: 144574

Objective-C classes. This has two purposes: to consistently provide
"forward declaration here" notes when we hit an incomplete type, and
to give LLDB a chance to complete the type.

RequireCompleteType bits from Sean Callanan!

llvm-svn: 144573

llvm-svn: 144572

[static analyzer] Tweak RetainCountChecker's diagnostics to correctly indicate if a message was due to a property access.  This can
potentially be refactored for other clients, and this is a regression from the refactoring of property acceses.

llvm-svn: 144571

llvm-svn: 144569

"kill". This looks like a bug upstream. Since that's going to take some time
to understand, loosen the assertion and disable the optimization when
multiple kills are seen.

llvm-svn: 144568

These annotations are disabled entirely when either ENABLE_THREADS is off, or
building a release build. When enabled, they add calls to functions with no
statements to ManagedStatic's getters.

Use these annotations to inform tsan that the race used inside ManagedStatic
initialization is actually benign. Thanks to Kostya Serebryany for helping
write this patch!

llvm-svn: 144567

llvm-svn: 144566

rdar://10412592

llvm-svn: 144565

[analyzer;Regionstore] handle loads from StringLiteral elements for StringLiterals representing wide strings.  Fixes PR 11294.

llvm-svn: 144563

Confirm should accept both "Y" and "y" in case somebody confuses the "default answer" indicator for a
directive to enter a capital letter.

llvm-svn: 144562

llvm-svn: 144561

llvm-svn: 144560

instructions of the two-address operands) in order to avoid inserting copies.
This fixes the few regressions introduced when the two-address hack was
disabled (without regressing the improvements).
rdar://10422688

llvm-svn: 144559

of the first type is the same as the aka string of the second type, but both
types are different.  Update the logic to print an aka for the first type to
show that they are different.

llvm-svn: 144558

Constant idx case is still done in tablegen but other cases are then expanded

Fixes <rdar://problem/10435460>

llvm-svn: 144557

[analyzer] teach AnalysisDeclContext::getSelfDecl() about blocks that capture the 'self' variable of the enclosing ObjC method decl.  Fixes <rdar://problem/10380300>.

llvm-svn: 144556

llvm-svn: 144555

llvm-svn: 144554

N32/64 places all variable arguments in integer registers (or on stack),
regardless of their types, but follows calling convention of non-vaarg function
when it handles fixed arguments.

llvm-svn: 144553

llvm-svn: 144552

PTX: Let LLVM use loads/stores for all mem* intrinsics, instead of relying on custom implementations.

llvm-svn: 144551

llvm-svn: 144550

argument registers on the callee's stack frame, along with functions that set
and get it.
    
It is not necessary to add the size of this area when computing stack size in
emitPrologue, since it has already been accounted for in
PEI::calculateFrameObjectOffsets.

llvm-svn: 144549

llvm-svn: 144548

I broke this in r144515, it affected most ARM testers.

<rdar://problem/10441389>

llvm-svn: 144547

llvm-svn: 144546

llvm-svn: 144545

a single argument.  We assumed that the : was
omitted from the selector name, but actually Clang
adds the : in the one-argument case.

llvm-svn: 144544

This still seems to be causing some failures.  It needs more testing before
it gets enabled again.

llvm-svn: 144543

llvm-svn: 144542

llvm-svn: 144539

llvm-svn: 144538

llvm-svn: 144537

llvm-svn: 144536

build/Make: Switch over to using llvm-config-2 for dependencies one more (hopefully last) time, now that it also builds as a build tool.

llvm-svn: 144535

cleans up all the chains allocated during the processing of each
function so that for very large inputs we don't just grow memory usage
without bound.

llvm-svn: 144533

tests when I forcibly enabled block placement.

It is apparantly possible for an unanalyzable block to fallthrough to
a non-loop block. I don't actually beleive this is correct, I believe
that 'canFallThrough' is returning true needlessly for the code
construct, and I've left a bit of a FIXME on the verification code to
try to track down why this is coming up.

Anyways, removing the assert doesn't degrade the correctness of the algorithm.

llvm-svn: 144532

this pass. We're leaving already merged blocks on the worklist, and
scanning them again and again only to determine each time through that
indeed they aren't viable. We can instead remove them once we're going
to have to scan the worklist. This is the easy way to implement removing
them. If this remains on the profile (as I somewhat suspect it will), we
can get a lot more clever here, as the worklist's order is essentially
irrelevant. We can use swapping and fold the two loops to reduce
overhead even when there are many blocks on the worklist but only a few
of them are removed.

llvm-svn: 144531

time it is queried to compute the probability of a single successor.
This makes computing the probability of every successor of a block in
sequence... really really slow. ;] This switches to a linear walk of the
successors rather than a quadratic one. One of several quadratic
behaviors slowing this pass down.

I'm not really thrilled with moving the sum code into the public
interface of MBPI, but I don't (at the moment) have ideas for a better
interface. My direction I'm thinking in for a better interface is to
have MBPI actually retain much more state and make *all* of these
queries cheap. That's a lot of work, and would require invasive changes.
Until then, this seems like the least bad (ie, least quadratic)
solution. Suggestions welcome.

llvm-svn: 144530