llvm-svn: 127837

This is done by lowering dbg.declare intrinsic into dbg.value intrinsic.
Radar 9143931.

llvm-svn: 127834

llvm-svn: 127832

llvm-svn: 127728

chose is having a non-memcpy/memset use and being larger than any native integer
type. Originally I chose having an access of a size smaller than the total size
of the alloca, but this caused some minor issues on the spirit benchmark where
SRoA runs again after some inlining.

This fixes <rdar://problem/8613163>.

llvm-svn: 127718

llvm-svn: 127716

llvm-svn: 127715

llvm-svn: 127684

llvm-svn: 127674

of pointers in an std::map.

llvm-svn: 127650

normal version.

Fixes rdar://9123638

llvm-svn: 127636

properties.
Added the self-wrap flag for SCEV::AddRecExpr.
A slew of temporary FIXMEs indicate the intention of the no-self-wrap flag
without changing behavior in this revision.

llvm-svn: 127590

llvm-svn: 127589

Early CSE pass so this patch reverts it to original source code.

llvm-svn: 127574

load and store reference same memory location, the memory location
is represented by getelementptr with two uses (load and store) and
the getelementptr's base is alloca with single use. At this point,
instructions from alloca to store can be removed.
(this pattern is generated when bitfield is accessed.)
For example,
%u = alloca %struct.test, align 4               ; [#uses=1]
%0 = getelementptr inbounds %struct.test* %u, i32 0, i32 0;[#uses=2]
%1 = load i8* %0, align 4                       ; [#uses=1]
%2 = and i8 %1, -16                             ; [#uses=1]
%3 = or i8 %2, 5                                ; [#uses=1]
store i8 %3, i8* %0, align 4

llvm-svn: 127565

llvm-svn: 127539

Optimize trivial branches in CodeGenPrepare, which often get created from the
lowering of objectsize intrinsics. Unfortunately, a number of tests were relying
on llc not optimizing trivial branches, so I had to add an option to allow them
to continue to test what they originally tested.

This fixes <rdar://problem/8785296> and <rdar://problem/9112893>.

llvm-svn: 127498

created from the", it broke some GCC test suite tests.

llvm-svn: 127477

InstCombine: Fix a thinko where transform an icmp under the assumption that it's a zero comparison when it's not.

Fixes PR9454.

llvm-svn: 127464

lowering of objectsize intrinsics. Unfortunately, a number of tests were relying
on llc not optimizing trivial branches, so I had to add an option to allow them
to continue to test what they originally tested.

This fixes <rdar://problem/8785296> and <rdar://problem/9112893>.

llvm-svn: 127459

Value, not an Instruction, so casting is not necessary. Also,
it's theoretically possible that the Value is not an
Instruction, since WeakVH follows RAUWs.

llvm-svn: 127427

after it has finished all of its reassociations, because its
habit of unlinking operands and holding them in a datastructure
while working means that it's not easy to determine when an
instruction is really dead until after all its regular work is
done. rdar://9096268.

llvm-svn: 127424

This happens a lot in clang-compiled C++ code because it adds overflow checks to operator new[]:
  unsigned *foo(unsigned n) { return new unsigned[n]; }
We can optimize away the overflow check on 64 bit targets because (uint64_t)n*4 cannot overflow.

llvm-svn: 127418

llvm-svn: 127362

llvm-svn: 127352

alloca as both integer and floating-point vectors of the same size. Bugpoint is
not cooperating with me, but I'll try to find a manual testcase tomorrow.

llvm-svn: 127320

a union of a float, <2 x float>, and <4 x float>. This mostly comes up with the
use of vector intrinsics, especially in NEON when programmers know the layout of
the register file. This enables codegen to eliminate a lot of the subregister
traffic it would otherwise generate.

This commit only enables this for a small number of floating-point cases, but a
lot more integer cases. I assume this is okay for all ports, but I did not do
extensive testing of the quality of code involving i512 vectors and the like. If
there is a use case where this generates worse code than before, let me know and
we can scale it back.

This fixes <rdar://problem/9036264>.

llvm-svn: 127317

more complicated.

llvm-svn: 127316

INT_MIN % -1.

llvm-svn: 127306

reachable uses, but there still might be uses in dead blocks.  Use the
standard solution of replacing all the uses with undef.  This is
a rare case because it's very sensitive to phase ordering in SimplifyCFG.

llvm-svn: 127299

llvm-svn: 127282

llvm-svn: 127220

llvm-svn: 127214

Radar 9097659

llvm-svn: 127182

then the result could go either way. If it's provably positive then so is the
srem. Fixes PR9343 #7!

llvm-svn: 127146

thing for variables.

llvm-svn: 127138

the value splatted into every element. Extend this to getTrue and getFalse which
by providing new overloads that take Types that are either i1 or <N x i1>. Use
it in InstCombine to add vector support to some code, fixing PR8469!

llvm-svn: 127116

InstCombine: We know the number of items initially added to the worklist map, reserve space early to avoid rehashing.

llvm-svn: 127089

the percentage of time spent in CodeGenPrepare when llcing 403.gcc from 12.6% to
1.8% of total llc time.

llvm-svn: 127069

possible. This goes into instcombine and instsimplify because instsimplify
doesn't need to check hasOneUse since it returns (almost exclusively) constants.

This fixes PR9343 #4 #5 and #8!

llvm-svn: 127064