llvm-svn: 168244

llvm-svn: 168240

test cases require fixes to fast-isel before the verifier can be enabled.
Part of rdar://12594152

llvm-svn: 168233

At the moment we still require to have an integer induction variable (for example: i++).

llvm-svn: 168231

llvm-svn: 168230

style requirement.

llvm-svn: 168229

Teach SROA rewriteVectorizedStoreInst to handle cases when the loaded value is narrower than the stored value. rdar://12713675

llvm-svn: 168227

llvm-svn: 168226

llvm-svn: 168225

llvm-svn: 168223

llvm-svn: 168221

llvm-svn: 168218

llvm-svn: 168215

They are just useless and prevent SmallVector from picking an optimized codepath
for memcpyable elements.

llvm-svn: 168211

llvm-svn: 168210

llvm-svn: 168208

This patch replaces the hard coded GPR pair [R0, R1] of
Intrinsic:arm_ldrexd and [R2, R3] of Intrinsic:arm_strexd with
even/odd GPRPair reg class.
Similar to the lowering of atomic_64 operation.

llvm-svn: 168207

llvm-svn: 168203

llvm-svn: 168202

llvm-svn: 168201

This fixes PR14359

llvm-svn: 168200

An alias to a function should use pc relative addressing.

llvm-svn: 168199

llvm-svn: 168198

Before, the parser would assert on the following code:

@a2 = global i8 addrspace(1)* @a
@a = addrspace(1) global i8 0

because the type of @a was "i8*" instead of "i8 addrspace(1)*" when parsing
the initializer for @a2.

llvm-svn: 168197

llvm-svn: 168196

llvm-svn: 168195

llvm-svn: 168191

ReleaseNotes.html updates reflecting PPC64 Elf Linux efforts and progress.

llvm-svn: 168189

but wasn't due to the same logic bug that caused PR14361.

llvm-svn: 168186

A PR is being filed to address some code issues here.

llvm-svn: 168185

llvm-svn: 168183

llvm-svn: 168182

replaced by this patch is equivalent to the new logic, but you'd be wrong, and
that's exactly where the bug was.  There's a similar bug in instsimplify which
manifests itself as instsimplify failing to simplify this, rather than doing it
wrong, see next commit.

llvm-svn: 168181

llvm-svn: 168180

llvm-svn: 168178

Patch by Pekka Jääskeläinen!

llvm-svn: 168176

Technically this is still a layering violation but it's header-only which makes
it less harmful. No functionality change.

llvm-svn: 168173

llvm-svn: 168171

llvm-svn: 168166

email address for completeness.

llvm-svn: 168165