llvm-svn: 169579

llvm-svn: 169578

llvm-svn: 169577

by virtue of inbounds GEPs that preclude a null pointer.

This is a very common pattern in the code generated by std::vector and
other standard library routines which use allocators that test for null
pervasively. This is one step closer to teaching Clang+LLVM to be able
to produce an empty function for:

  void f() {
    std::vector<int> v;
    v.push_back(1);
    v.push_back(2);
    v.push_back(3);
    v.push_back(4);
  }

Which is related to getting them to completely fold SmallVector
push_back sequences into constants when inlining and other optimizations
make that a possibility.

llvm-svn: 169573

llvm-svn: 169572

Makefile.common: Update a description, s/Source/SOURCES/ , according to MakefileGuide.html#control-variables .

llvm-svn: 169569

  - Use SOURCES instead of Source. See Makefile.rules and MakefileGuide.html.
  - Don't assume the current directory. $(wildcard *.cc) doesn't match anything on corresponding build directory.

llvm-svn: 169568

llvm-svn: 169565

llvm-svn: 169564

decide what pattern we want to follow in the future.

llvm-svn: 169561

1) don't delete gtest-all.cc (which is used to gather all gtest source
   files in a single file) 
2) make including LLVMSupport headers optional (on by default).
   Sanitizer tools may want to use their own versions of googletest
   compiled with specific flags, instead of the common googletest
   library used for all other LLVM/Clang unittests.

llvm-svn: 169559

fixed valgrind issues of prior commit, this change applies r169456 changes back to the tree with fixes. on darwin no valgrind issues exist in the tests that used to fail.

original change description:

change MCContext to work on the doInitialization/doFinalization model

reviewed by Evan Cheng <evan.cheng@apple.com>

llvm-svn: 169553

llvm-svn: 169551

llvm-svn: 169550

Patch by Alexander Zinenko.

llvm-svn: 169547

llvm-svn: 169546

Jordan and I discussed this, and we don't want this in the API.

llvm-svn: 169541

understand target implementation of any_extend / extload, just generate
zero_extend in place of any_extend for liveouts when the target knows the
zero_extend will be implicit (e.g. ARM ldrb / ldrh) or folded (e.g. x86 movz).

rdar://12771555

llvm-svn: 169536

llvm-svn: 169534

This is an alternative to the ImmutableMapRef interface where a factory
should still be canonicalizing by default, but in certain cases an
improvement can be made by delaying the canonicalization.

llvm-svn: 169532

llvm-svn: 169521

check if loads that happen in between stores alias with the first store in the
chain, only with the second store onwards.

llvm-svn: 169516

llvm-svn: 169504

llvm-svn: 169491

Instead of unconditionally storing origin with every application store,
only do this when the shadow of the stored value is != 0.

This change also delays instrumentation of stores until after the walk over
function's instructions, because adding new basic blocks confuses InstVisitor.

We only keep 1 origin value per 4 bytes of application memory. This change
fixes the bug when a store of a single clean byte wiped the origin for the
whole 4-byte area.

Since stores of uninitialized values are relatively uncommon, this change
improves performance of track-origins mode by 5% median and by up to 47% on
specs.

llvm-svn: 169490

s/getLowerBoundDefault/getDefaultLowerBound/ for consistency. Also put the more natural check first in the if-then statement.

llvm-svn: 169486

Some languages, e.g. Ada and Pascal, allow you to specify that the array bounds
are different from the default (1 in these cases). If we have a lower bound
that's non-default, then we emit the lower bound. We also calculate the correct
upper bound in those cases.

llvm-svn: 169484

Remove intrinsic specific instructions for (V)MOVQUmr with patterns pointing to the normal instructions.

llvm-svn: 169482

llvm-svn: 169477

llvm-svn: 169464

llvm/test/CodeGen/ARM/extload-knownzero.ll: Try to unbreak, to add -O0. I guess Chad expects fastisel here.

llvm-svn: 169463

It broke many builders.

llvm-svn: 169462

rdar://12821569

llvm-svn: 169460

and extload's. If they are implemented as zero-extend, or implicitly
zero-extend, then this can enable more demanded bits optimizations. e.g.

define void @foo(i16* %ptr, i32 %a) nounwind {
entry:
  %tmp1 = icmp ult i32 %a, 100
  br i1 %tmp1, label %bb1, label %bb2
bb1:
  %tmp2 = load i16* %ptr, align 2
  br label %bb2
bb2:
  %tmp3 = phi i16 [ 0, %entry ], [ %tmp2, %bb1 ]
  %cmp = icmp ult i16 %tmp3, 24
  br i1 %cmp, label %bb3, label %exit
bb3:
  call void @bar() nounwind
  br label %exit
exit:
  ret void
}

This compiles to the followings before:
        push    {lr}
        mov     r2, #0
        cmp     r1, #99
        bhi     LBB0_2
@ BB#1:                                 @ %bb1
        ldrh    r2, [r0]
LBB0_2:                                 @ %bb2
        uxth    r0, r2
        cmp     r0, #23
        bhi     LBB0_4
@ BB#3:                                 @ %bb3
        bl      _bar
LBB0_4:                                 @ %exit
        pop     {lr}
        bx      lr

The uxth is not needed since ldrh implicitly zero-extend the high bits. With
this change it's eliminated.

rdar://12771555

llvm-svn: 169459

change MCContext to work on the doInitialization/doFinalization model

reviewed by Evan Cheng <evan.cheng@apple.com>

llvm-svn: 169456

llvm-svn: 169455

llvm-svn: 169452

Evan nominated me for this a while back, and no one has offered to
save me from it.

llvm-svn: 169447

llvm-svn: 169446

llvm-svn: 169443