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

Previously, MBP essentially aligned every branch target it could. This
bloats code quite a bit, especially non-looping code which has no real
reason to prefer aligned branch targets so heavily.

As Andy said in review, it's still a bit odd to do this without a real
cost model, but this at least has much more plausible heuristics.

Fixes PR13265.

llvm-svn: 161409

llvm-svn: 161408

This is useful for example for %n in printf, which expects
a pointer to int with the same logic for checking as %d
would have in scanf.

llvm-svn: 161407

llvm-svn: 161406

if checked out under clang/tools/extra.

This is mostly so folks other than me can start to test. Documentation,
details, and an announcement are still in the works.

llvm-svn: 161405

With this we can build and test the remove-cstr-calls tool which should
serve as a good example of how to add tools and their tests to the
repository.

llvm-svn: 161404

Also remove redundant constructors and unused member functions.

llvm-svn: 161403

the new tools repo to preserve history. I'll subsequently be editting these
down to work w/ the tooling test suites.

llvm-svn: 161402

to preserve its history. It's not yet functional.

llvm-svn: 161401

repository.

llvm-svn: 161400

llvm-svn: 161399

llvm-svn: 161398

If the result of a common subexpression is used at all uses of the candidate
expression, CSE should not increase the live range of the common subexpression.

rdar://11393714 and rdar://11819721

llvm-svn: 161396

non-POD. Fixes <rdar://problem/12031870>.

llvm-svn: 161395

--- Reverse-merging r161371 into '.':
U    include/llvm/Target/TargetData.h
U    lib/Target/TargetData.cpp

llvm-svn: 161394

update implementation to match. An elidable, non-trivial constructor call is a
side-effect under this definition, but wasn't under the old one, because we are
not required to evaluate it even though it may have an effect.

Also rationalize checking for volatile reads: just look for lvalue-to-rvalue
conversions on volatile glvalues, and ignore whether a DeclRefExpr etc is for
a volatile variable.

llvm-svn: 161393

llvm-svn: 161392

llvm-svn: 161391

llvm-svn: 161390

included in warning groups.  Warning groups can only contain warnings, because only
warnings can be mapped to errors or ignored.

This caught a few diagnostics that were incorrectly in diagnostic groups, and
could have resulted in a compiler crash when those diagnostic groups were mapped.

Fixes <rdar://problem/12044436>

llvm-svn: 161389

was mistakenly classifying dynamic_casts which might throw as having no side
effects.

Switch it from a visitor to a switch, so it is kept up-to-date as future Expr
nodes are added. Move it from ExprConstant.cpp to Expr.cpp, since it's not
really related to constant expression evaluation.

Since we use HasSideEffect to determine whether to emit an unused global with
internal linkage, this has the effect of suppressing emission of globals in
some cases.

I've left many of the Objective-C cases conservatively assuming that the
expression has side-effects. I'll leave it to someone with better knowledge
of Objective-C than mine to improve them.

llvm-svn: 161388

Fixing an issue where ValueObject::GetPointeeData() would not work correctly for file addresses when fetching items other than the 0-th

llvm-svn: 161384

require an AddressClass, which is useless at this
point since it already knows the distinction between
32-bit Thumb opcodes and 32-bit ARM opcodes.

llvm-svn: 161382

Fixed an error in the thumb opcode encoding. We need the 32 bit thumb instructions to be encoded as a 32 bit value for the EmulateARM code.

llvm-svn: 161381

This is an additional test for r161349 (ignoring 10.8's annotations for
NSMakeCollectable).

llvm-svn: 161380

just let the alignment be zero.

PR13531

llvm-svn: 161379

llvm-svn: 161378