The getSumForBlock function was quadratic in the number of successors
because getSuccWeight would perform a linear search for an already known
iterator.

llvm-svn: 161460

multiple scalar promotions on a single loop. This also has the effect of
preserving the order of stores sunk out of loops, which is aesthetically
pleasing, and it happens to fix the testcase in PR13542, though it doesn't
fix the underlying problem.

llvm-svn: 161459

memory models, except when arc is accessing a weak
ivar (which is an error). // rdar://6505197

llvm-svn: 161458

llvm-svn: 161455

llvm-svn: 161454

This adds support for TargetIndex operands during isel. The meaning of
these (index, offset, flags) operands is entirely defined by the target.

llvm-svn: 161453

An unsigned value converted to floating-point will always be greater than
a negative constant.  Unfortunately InstCombine reversed the check so that
unsigned values were being optimized to always be greater than all positive
floating-point constants.  <rdar://problem/12029145>

llvm-svn: 161452

do so when the high bits are known zero. This caused a subtle miscompilation.

rdar://12027825 

llvm-svn: 161451

and the other is a glvalue of class type, don't forget to copy-initialize a
temporary when performing the lvalue-to-rvalue conversion on the glvalue.
Strangely, DefaultLvalueConversions misses this part of the lvalue-to-rvalue
conversions.

llvm-svn: 161450

for side-effects. Instead, check for side-effects after performing
initialization. Doing so also removes some strange corner cases and differences
between in-class initialization and constructor initialization.

llvm-svn: 161449

objc_release for performance for these most often
called APIs. // rdar://12040837

llvm-svn: 161448

implementation was changed to a union of bitfields.

llvm-svn: 161447

character arrays. This is in line with what GCC does.
<rdar://problem/10529227>

llvm-svn: 161446

llvm-svn: 161445

If you build with -fobjc-arc, then -fobjc-link-runtime is implied but we
don't need to warn about it being unused in that case.  rdar://12039965

llvm-svn: 161444

llvm-svn: 161443

Comment XML: add a root node kind for enums.

llvm-svn: 161442

A target index operand looks a lot like a constant pool reference, but
it is completely target-defined. It contains the 8-bit TargetFlags, a
32-bit index, and a 64-bit offset. It is preserved by all code generator
passes.

TargetIndex operands can be used to carry target-specific information in
cases where immediate operands won't suffice.

llvm-svn: 161441

Warns on anti-patterns/typos in the 'size' argument to strncat. The
correct size argument should look like the following:
 - strncat(dst, src, sizeof(dst) - strlen(dest) - 1);

We warn on: 
 - sizeof(dst)
 - sizeof(src)
 - sizeof(dst) - strlen(dst)
 - sizeof(src) - anything

(This has been implemented in void Sema::CheckStrncatArguments().)

llvm-svn: 161440

llvm-svn: 161439

llvm-svn: 161438

llvm-svn: 161437

llvm-svn: 161436

llvm-svn: 161435

llvm-svn: 161434

Compare the critical paths of the two traces through an if-conversion
candidate. If the difference is larger than the branch brediction
penalty, reject the if-conversion. If would never pay.

llvm-svn: 161433

llvm-svn: 161432

The implementation also includes a Relax NG schema and tests for the schema
itself.  The schema is used in c-index-test to verify that XML documents we
produce are valid.  In order to do the validation, we add an optional libxml2
dependency for c-index-test.

Credits for CMake part go to Doug Gregor.  Credits for Autoconf part go to Eric
Christopher.  Thanks!

llvm-svn: 161431

llvm-svn: 161430

a use or a BB, but it is inline in the handling of the invoke instruction.

This patch refactors it so that it can be used in other cases. For example, in

define i32 @f(i32 %x) {
bb0:
  %cmp = icmp eq i32 %x, 0
  br i1 %cmp, label %bb2, label %bb1
bb1:
  br label %bb2
bb2:
  %cond = phi i32 [ %x, %bb0 ], [ 0, %bb1 ]
  %foo = add i32 %cond, %x
  ret i32 %foo
}

GVN should be able to replace %x with 0 in any use that is dominated by the
true edge out of bb0. In the above example the only such use is the one in
the phi.

llvm-svn: 161429

Thanks to Alex Rosenberg for the suggestion.

llvm-svn: 161428

Allow direct ivar access in init and dealloc methods
in mrr. // rdar://650197

llvm-svn: 161426

llvm-svn: 161420

llvm-svn: 161419

[compiler-rt] CMake build: if LLVM_BUILD_32_BITS is on, then -m32 is added to llvm definitions. Let us override this by explicitly adding -m64 compiler flag when building compiler-rt libraries for x86_64 target

llvm-svn: 161415

and "instruction address -> file/line" lookup.

Instead of plain collection of rows, debug line table for compilation unit is now
treated as the number of row ranges, describing sequences (series of contiguous machine
instructions). The sequences are not always listed in the order of increasing
address, so previously used std::lower_bound() sometimes produced wrong results.
Now the instruction address lookup consists of two stages: finding the correct
sequence, and searching for address in range of rows for this sequence.

llvm-svn: 161414

We give a bonus for every argument because the argument setup is not needed
anymore when the function is inlined. With this patch we interpret byval
arguments as a compact representation of many arguments. The byval argument
setup is implemented in the backend as an inline memcpy, so to model the
cost as accurately as possible we take the number of pointer-sized elements
in the byval argument and give a bonus of 2 instructions for every one of
those. The bonus is capped at 8 elements, which is the number of stores
at which the x86 backend switches from an expanded inline memcpy to a real
memcpy. It would be better to use the real memcpy threshold from the backend,
but it's not available via TargetData.

This change brings the performance of c-ray in line with gcc 4.7. The included
test case tries to reproduce the c-ray problem to catch regressions for this
benchmark early, its performance is dominated by the inline decision of a
specific call.

This only has a small impact on most code, more on x86 and arm than on x86_64
due to the way the ABI works. When building LLVM for x86 it gives a small
inline cost boost to virtually any function using StringRef or STL allocators,
but only a 0.01% increase in overall binary size. The size of gcc compiled by
clang actually shrunk by a couple bytes with this patch applied, but not
significantly.

llvm-svn: 161413

llvm-svn: 161412

llvm-svn: 161411

instsimplify+inline strategy.

The crux of the problem is that instsimplify was reasonably relying on
an invariant that is true within any single function, but is no longer
true mid-inline the way we use it. This invariant is that an argument
pointer != a local (alloca) pointer.

The fix is really light weight though, and allows instsimplify to be
resiliant to these situations: when checking the relation ships to
function arguments, ensure that the argumets come from the same
function. If they come from different functions, then none of these
assumptions hold. All credit to Benjamin Kramer for coming up with this
clever solution to the problem.

llvm-svn: 161410